Amiga Developer CD v2.1/Amiga Developer CD v2.1.iso/Contributions/Heinz_Wrobel/Networking/Envoy_3.0/FixedBugs

Text File | 1998-10-27 | 179KB | 2,993 lines

/*------------------------------------------------------------------------*/
/*                                                                        *
 *  $Id: FixedBugs 1.19 1998/10/27 21:57:27 heinz Exp $
 *                                                                        */
/*------------------------------------------------------------------------*/

Informal list of fixed bugs and changes since Envoy 1.65
========================================================

[Really important behaviour changes that need to be documented are marked
 with '!!']

    - Crash on aborting examines (C:LIST, CTRL-C).
    - FindService() returning garbage error codes.
    - GetHostName() appending LocalHost to the passed buffer for a NULL
      enitity passed.
    - Crashes in HostRequestA(). Lousy GUI code. Fixed for now. Should
      be replaced.
    - Repaired half a ton of "cast" bugs. Lots of code used
      inappropriate and sometimes really destructive casts.
    - NIPCBuffer trashing on local ACTION_READ and ACTION_WRITE.
    - endless retry on security reject which in essence hangs the client
      and loads the line.
    - filesystem.service used to open after one failed open if
      nipc.library was available, even if the other libraries needed
      were not. Net result ==> GURU!
    - ACTION_SET_FILE_SIZE should work now.
    - hanging lock on security failure when trying to enter a directory.
    - fs server left locks on failing mount requests for non existing volumes.
    - on mount fs server reported "doesn't exist" when it in fact rejected the
      user.
    - server had serious problems with handling requester suppression on a
      mount.
    - ACTION_FH_FROM_LOCK works now.
    - fcconfig deleted temporary ".info" file manually. It now uses
      DeleteDiskObject().
    - fsconfig did not really fit onto a 640x200 topaz 8 WB.
    - The fs code and the fs prefs code duplicated many structures and
      defines which should have been defined in one place only to avoid
      compatibility breaks. Fixed now. Referencing includes across
      directories is not nice but a lot better than duplicating their
      contents arbitrarily. I need to do something about nipc, too.
    - Cleaned out obsolete intuition identifiers where I found them.
    - Groups prefs has now a better login.
    - About menus added to the filesystem prefs editors.
    - An english locale text for the nipc prefs was too long. Fixed.
    - Small kludge added to nipc.library to have Envoy 1.65 behaviour on
      the S2 CopyFromBuffer callback. Envoy 1.65 always returned success on
      this callback no matter what. Hmm. DO NOT DEPEND ON THIS!
    - Missing Permit() in FindEntity() code could potentially have stopped
      the system.
    - nipc S2 code could leave buffer lying around on low memory.
    - nipc S2 code did not necessarily queue ARP requests again when
      the remote side came back into service.
    - internal nipc S2 packet counters for internal statistics were not
      handled correctly. Doesn't matter for the user though. This
      was more a cosmetic fix.
    - nipc UDP closed connection via Forbid() protection while the list was
      otherwise semaphore protected.
    - nipc ARP buffer entry timeout value was wrong by a factor of 10.
    - nipc doesn't depend on services.library internals anymore.
      services.library V40(!) has special private access functions
      now. services manager uses these for locking now, too.
    - CreateEntityA() made the entity available before it was fully
      initialised. If this was done just at the "right" time,
      nipc.library would crash or do other strange things.
    - nipc RDP made an active connection available on open before having
      set up all data needed.
    - gross bugs in nipc RDP handling. The headerlength was not set according
      to RFC908 and on dataless "flag" packets the wrong sequence number
      was used! Actually I am not sure if RDP works as described in
      RFC908/1151 at all. The code looks more like "we do it not quite like
      they do it" which really is annoying.
    - dataless RDP packets updated the sequence number of the last ack'ed
      packet to the current one even if there was no ack!
    - nipc RDP data acceptance via PacketIn() had major problems:

        - If a needed packet in sequence did not arrive, it would continue
          to queue even redundant packets until death.
        - In two places it had search algorithms with an O(n^2) like
          brute force approach to the problem. Hmpfh.
        - it ack'ed segments but did not tell the timeout code that those
          segments were acked. So the timeout code sent another ack.

      I rewrote this completely. No reasonable way to fix it without
      throwing it out.
    - nipc RDP code would in some cases either dereference NULL pointers
      or other invalid list pointers, access closed (non existing!)
      connections, or send spurious resets to the other side with garbage
      sequence numbers.
    - On closing nipc RDP connections in the listening state, the RDP code
      sent a reset to some undiscovered country.
    - nipc RDP resets were not necessarily obeyed.
    - While checking on some nipc stuff I found that NIPCConfig would
      really barf on you if you tried to use the Realm configuration
      screen. As it turned out, someone used "mlh_Tail" instead of
      "mlh_TailPred" for walking a list.
    - nipc AMP code cleared out all the RDP flags when it had been
      signaled on an available transmit window. '!' was used for inverting
      a bit mask rather than '~' in three places scattered in
      BeginTransaction() and ReplyTransaction()! A sure killer IMHO.
      The same bug was in DeleteEntity() in handling entity flags.
      Just wondering: How did nipc work at all? ;^) :-(
    - nipc RDP will now flush still pending writes when they are
      acknowledged, not only on a timeout run after it has timed out!
    - On startup nipc will do better checking of any sana2 device it tries
      to open. This fixes e.g. an open amoksana.device with no HW
      connected.
    - If a sana2 device goes into "failure mode" and barfs on any and
      all requests for some reason, nipc.library would hog the CPU
      and in effect lock the system. Error handling tries to be
      smarter now, even though there is no true general solution to
      the problem. This should help in most cases, though.
    - FindEntity() messed with an entity after releasing the entity list
      semaphore. Tiny window, but a window.
    - password hook in the login requester fixed. Now it is possible to
      delete a password that is too long and retype it.
    - printer prefs and Users are now localised.
    - Strange double click behaviour in Filesystem Imports ListView
      fixed.
    - fixed potential holes in nipc sana 2 code that could have messed up
      sana 2 addresses with a bit count that is not a multipe of eight.
    - nipc sana 2 code did not clear allocated IORequest memory in all
      cases. This could have caused strange flag settings etc.
 !! - nipc ARP will now be used for all HW types, not just for
 !!   ethernet connections. This is an incompatible change but fixes
 !!   the HW address vs. IP address dependency problems.
 !! - If the user chose defaults for IP and ARP type in the network
 !!   configuration for a device, he will get ethernet values 2048 and 2054
 !!   unless ARCNET is used. Then 240 and 241 are used as defaults
 !!   in nipc.library. While this is not a good solution at all as it
 !!   doesn't take into account the actual HW available, it will at
 !!   least give reproducible results compared to the "ignore the
 !!   checkmarks and take whatever we have" type of behaviour.
    - There is a major conceptual problem with RDP sequence number wrap
      around. This always has and still does completely confuse the RDP
      code and will in effect make the RDP connection affected unusable and
      probably flood the net with packet retransmits that are never
      correctly acknowledged. I am in the process of doing something about
      this, but this is a _very_ tricky subject. Hopefully my rework
      of sequence number handling works. This needs more testing.
    - With my RDP rework I added a new bug affecting the start up of a
      connection. For fixing this bug I did some heavy RDP debugging.
      So RDP connections should work a lot better now. Especially
      starting up an RDP connection should be now as fast as it used
      to be again. Again, the new release might be incompatible to
      previous buggy releases. Sorry for the inconvenience. We are now
      at nipc.library 40.18.
    - Changed the printspool.service naming convention for jobs from
      "t:job%ld" to "T:EnvoyPrintJob_%ld" to avoid any conflicts.
    - Services Configuration should no longer leave filelocks or library opens
      hanging! It will also default to "/Services" now as directory for
      adding services (it is based in Configurations!). This should help
      poor B. J. User somewhat.

    - Back to the filesystem. ACTION_READ_LINK returned DOSTRUE and
      ERROR_ACTION_NOT_KNOWN for some strange reason. Fixed. This shouldn't
      have been a problem anyway as ReadLink() should only be called if
      ERROR_IS_SOFT_LINK has been returned by the FS, which of course
      cannot happen.
    - Found a hole in internal restarts of ExAll type requests.
      Packets were added to the head of the main FS packet port
      without any protection at all!
    - ACTION_MAKE_LINK will now work for hard links. This might
      e.g. help DUUCP users with a networked news tree.
    - I decided to finally try it: Record locking should work now.
      This needs more testing though for reliability.
    - ACTION_DELETE_OBJECT may take a lot longer for large files than
      pretty much any other packet. So the default timeout of 6
      seconds was not enough and even though the packet succeeded, the
      network transaction timed out. I bumped the timeout to 18
      seconds for a delete. This stuff shouldn't be done via a single
      transaction, but it is not at all easy to rewrite!
      Bumping the timeout is not a solution but it'll make the situation
      at least a lot better for most users.
    - Really nasty bug on reconnect of a broken network mount. The
      client passed the full server path of the object in question
      without the server drive specifier. This could lead to write
      files popping up in strange places suddenly and read files not
      to reconnect. Same problem fixed for locks.
    - ACTION_READ/ACTION_WRITE could still leave buffers lying around on
      failure. Should be fixed now.
    - ACTION_READ/ACTION_WRITE would pretty much garble the client seek
      position on network failure or partial R/W failure. Now a bona fide
      attempt is done to keep the seek position correct. This might still
      fail of course, but this is better than not doing anything at all
      about it.
    - While an ACTION_READ/ACTION_WRITE is pending all incoming packets for
      this file handle are saved and queued again after the R/W is
      complete. The packets were requeued in reversed order and without
      sufficient list protection.
    - I found a reproducible case where after a reconnect the client was
      accessing the root of the mounted server drive where the network
      volume is located, and not the root of the network volume.
    - The server did not clean up exall handling for locks discarded on
      a dead mount.
    - The client/server had an internal concept of a -1 lock which
      represented the current server directory on reconnect. No code
      used this feature for anything useful and it messed up
      reconnections with volume relative paths. I took it out.
      Reconnect works volume base relative now.
    - ACTION_EXAMINE_ALL was commented out on the client side. Why? Because
      it was totally and absolutely f...ouled up in many subtle ways
      on both the client and server side. It should work now. Please
      test this and all the bells and whistles like eac_MatchFunc in
      detail. Why I did all this work? Because EXAMINE_ALL and all the
      other examine functions share common code. So I had to fix it.
    - ACTION_EXAMINE_NEXT could be ended prematurely, pulling out the rug
      under the client while doing this.
    - The server tried to filter filenames in the examine calls even
      if there was no buffer space set up.

    - Did some autodoc typo fixes in nipc.library.
    - Tiny change in nipc.library's buffer handling. What is
      externally visible as AppendNIPCBuff() will now move the list of
      buffer entries in one piece instead of entry after entry. This
      saves some CPU time. I improved this on the way as I found a
      possible cause for an enforcer hit in low memory situations.
      Found this due to a bug report on nipc enforcer hits that were
      actually caused by the fs code.
    - With the fs update, I introduced a bug in R/W buffer handling
      that could cause enforcer hits in nipc.library under certain
      network failure situations. Fixed, hopefully.
    - Interesting enough, I cultivated a bug in exall handling when
      redoing the exall stuff. The matchstring was passed to the
      server to filter entries. While this is in theory a neat idea
      by the C= guys to save on the actual transfer, it doesn't work
      as I know now. Preparsed patterns are not portable between
      different dos.library versions. Now all the filtering is done on
      the client side. This is unfortunately much less efficient.
    - Another bug was in filtering of exall entries on the client
      side. It did not remove entries correctly in all cases.

    - The sana2 code in nipc.library could "forget" to requeue packets for
      ARP under certain conditions. It also queued read packets for devices
      known to be offline which is totally useless and hogs the CPU.
    - Slight rework of R/W packet handling to be on the safe side. I
      _think_ I found the hole causing spurious enforcer hits via
      nipc.library once in a while, but I am not sure yet.

    - "Network Configuration" will no longer force the realm
      checkboxes set, just because there are entries in the realm
      lists. This makes it possible to turn off a realmserver without
      loosing the entered prefs data.
    - It should be possible now to use the RETURN key in the "Network
      Configuration" "Host Configuration" panel to hop from gadget to
      gadget just like with all the other panels.
    - There is still a bug in the RDP code when a packet sequence number
      wrap around occurs. I found this based on a hunch regarding the
      "overnight hanging bug". This bug in effect breaks the
      connection. I have started to investigate and fix this, and as a
      result the new nipc.library will once again be absolutely
      incompatible to previous versions. Sorry. A side effect of my
      work for a fix is that some fields are now 32 bit aligned which
      should help on anything >=68020, i.e. >= A1200.
    - Sequence number wraparound should be ok now. Finally.
    - Fixed a few holes in the RDP code where a task waiting on RDP
      permission to send stuff would sleep forever. When this happened
      due to the sequence number wrap around bug, this connection
      would effectively hang. This should explain and fix the
      "overnight hangs" for good. I hope there isn't more of this.
      We are now at nipc.library 40.24.

    - Note that nipc will not use trans_Timeout for local transactions
      currently. So a local entity connection will hang if the
      destination hangs. The source has no chance to recover. I feel
      that this is a bug (which is currently hard to fix). What do you
      think? COMMENTS ARE WELCOME!
    - The server could show erratic behaviour if you sent paths longer than
      128 characters to ACTION_LOCATE/DELETE_OBJECT and ACTION_CREATE_DIR.
    - ACTION_SET_DATE would return garbage results on a security failure.
    - ACTION_CHANGE_MODE was flaky with filehandles before. Should work now.
    - fs server locked a semaphore a few lines to late. No problem with
      normal use, but still a bug.
    - On cleaning up dead mounts, the server left a lock lying around.
    - The client was flaky with timeout settings on reconnect. This could
      hang a reconnect.
    - Unlocking NULL locks is not nice, but should be regarded as ok. This
      is now the case.
    - Believe it or not, I found another nipc bug. If you deleted a public
      entity that still had connections pending, it would be silenced as
      far as possible, but not be made private. This would lead to enforcer
      hits if a remote side tried to enumerate entities. As a side effect of
      my fix, FindEntity() will now behave according to spec and only find
      local entites if they were created with ENT_Public, just like with
      remote entities. We are now up to nipc.library 40.25. How many
      revision will there be?
    - ACTION_DELETE_OBJECT will now run async on the server. It should
      no longer block server activity for other clients until the
      delete is done. The client will get a response when the delete is
      done, but the server is not locked up for other clients in the
      meantime.
    - The client is now a little better about doing at least one retry with
      a prolonged timeout itself before putting up a requester. So
      timeout requesters will come later now.
    - EFS should behave _much_better_ now with server drives having RMS. It
      used to barf in many ways, now it should handle this rather
      gracefully and hopefully do the right thing in all cases. As this
      needs truly tons of testing, I hesitate to say that Envoy has RMS
      now. While the mounts on the client turn up as public entities now,
      it won't make any sense for a user to FindEntity() them. They are
      public only to let the server be able to contact them in majik wayz.
      Please try this with CDx: and DFx: and whatever you got. Note that
      RMS does not carry across machines. You can't export a volume in
      df0:, get locks on it on the client, move the disk physically to the
      client's disk drives and expect it to be recognized.
 !! - A BEHAVIOUR CHANGE of fs exports. An export with an empty export
 !!   name used to get the clients device mount name. Now it will get
 !!   the true volume name of the servers volume. This makes much more
 !!   sense and an empty name is now the preferred setting for
 !!   exporting a DOS device with RMS. Actually it is probably
 !!   reasonable to say a few things about RMS name handling and
 !!   reconnect behaviour now. As described above the client used to
 !!   have the same name for the volume node as for the client's
 !!   device node if no export name was specified on the server. This
 !!   was not logical, as both the export and import prefs listed the
 !!   server's export path (typically a device name) in this case. In
 !!   this case the client can make much more use of the server's
 !!   volume name. All this does not affect name use of the client at
 !!   all, as of course the device node is still there and any
 !!   reference to that name will now go via the device node instead
 !!   of the volume node. Nothing is lost. The client just has
 !!   additional information available via the correct volume node.
 !!   RMS and reconnect are related to the above. If an export name is
 !!   configured on the server, it will be only used on a mount of an
 !!   inserted volume or a reconnect (which is in effect a remount).
 !!   If no name is configured the true volume name will be used. For
 !!   any disk change, only the true volume nname will be used. Why?
 !!   because having different active volumes with all the same name
 !!   doesn't make much sense. So there is one simple rule now: If you
 !!   export a drive/device with RMS, don't specify an export name.
    - the server should no longer work with garbage guid/uid's on low
      memory situations.
    - I got tired of rebooting, so now the server supports file
      notification on its prefs file in ENV:. One can change the
      export configuration on the fly now. The Services Manager
      will also try to reload its configuration now if it has been
      changed. Note that this cannot (and probably should not) be done
      easily for nipc due to how all the stuff works.
    - Added a "Use" button to the fs export prefs and appropriate menu
      headers to select env: or envarc: values. Default is empty.
    - Services Prefs behaved strange when using the "Last Saved" menu.
      It appended the stuff to the current list of services.
    - Notification should be working now. Some special notes about
      this, though:
        a) Any action done through EFS that should cause a
           notification of the client, will cause one (Guru Book!).
           The ROM fs and RAM handler don't do it that way.
        b) Any action done through the server fs will cause a
           notification if that fs supports notification for the
           action. Needed to get notifed of other's accesses.
        c) As a result, any action done through EFS will cause
            1 notification event if only EFS supports it, and
            2 notification events if both EFS and the server fs
            support it.
      While two events can be annoying at times, they are better than
      none at all. I have no way to tell which actions on the server
      side fs will cause a notification by that fs and which won't.
      Please test this with both signal and message notification and
      whatever flags there are, and with reconnect!
    - The login requester password hook was a pain. I removed editing
      restrictions now to make it work. For users that get lost in
      typing in dots this means, they probably better kill the contents
      and retype in some cases.
    - The printer server should now process spooled client files in 8k
      chunks instead of 1k chunks. This _might_ help efficiency.
    - ACTION_WRITE_PROTECT is supported now. It will leave the server
      untouched and do only client side write protection.
    - Another change for ACTION_DELETE_OBJECT. While it doesn't block
      server operation anymore for other mounts, all packets for the
      client mount of the delete will be queued until the delete is
      done and processed afterwards. Why? To guarantee sequential
      behaviour in packet processing. Note: PLEASE TEST THIS! Maybe by
      sending of an async delete packet and sending other packets
      before the reply comes in. I don't trust my own tests at all
      here. This stuff is tricky.
    - String gadgets in Login/Host requester will be activated on
      window activation.
    - String gadget contents in Host requester will now be used even if
      it wasn't deactivated by TAB/ENTER.
    - I decided not to do anything about the string gadgets in Network
      Configuration, Users, and Groups. This doesn't hurt too much and
      would require some rewrite.
    - I think I found the "split file on reconnect" bug. Finally. A
      baselock for a path of a file to open was assumed to be the
      parent lock of the file itself. So any path specs in the file
      name got lost on the way which messed up paths for reconnect.
    - As Dale correctly said, the printer stuff is FUBAR. Unless there
      are any error reports, I probably won't touch it again. it needs
      to be rethought and rewritten from scratch.
    - Due to all the changes outlined above, I decided to call this
      Envoy 2.0, not 1.8.

    - Services Configuration has now "Enabled:" again as english label
      for the checkbox. For <V39 systems, I removed the display of the
      currently selected service under the listview. There was no
      reasonable way to get it to look nice on < 3.0 and >= 3.0.
      This type of "bug fix" has been done to some other prefs editors
      previously by C=. Probably for the same reason. It doesn't hurt
      the user interface though. While doing this I found that
        a) memory was left lying around when adding a bad service
        b) an asl requester was freed twice while another wasn't freed
           at all on exit. Automatic reboot included.
      We are now at 37.13.
    - Enforcer hit in nipc.library fixed. I introduced this bug with
      my fixes for 40.25. Now we are at 40.26.
    - A minor problem with notification in the fs server. Notification
      was not done for the parent directory of the modified object.
      Notification for objects referenced with a lock and an empty
      file name could have been flaky. This should be ok now. I did
      not mention one other thing before: Notification should
      theoretically be done on all the hard links of the modified
      object, too. If you think about it hard, you will realise that
      this is not possible. This is not a bug. Anyway, the server is
      now up to 40.29.
    - This is embarassing. I left in debugging code that delayed a
      notification setup for > 1 second. Server is now at 40.30.
    - The AmiCDRom filesystem doesn't seem to set up its struct Resident
      correctly. This caused hits on volume insertion. I put a kludge into
      the fs server to compensate for this problem. Now at 40.31.
    - The client sets the DiskType in the volume nodes now. This should
      help "Filesystem Imports" to decide on already mounted mounts. Now at
      40.41.
    - Minor typo fixes in some doc files and minor german locale update.
    - Filesystem Imports complained on empty drives even if the mount was
      ok. Fixed. It should be a lot better about determining which drives
      are already mounted, too. The original code had "crashy" tendencies
      for removable media and did not take device mounts into account.
      Now at 40.9.

    - Filesystem Imports will now check only active Envoy mounts to
      see if they are already mounted. Inactive mounts should be left
      alone for sure, now. Now at 40.10
    - The efs client did some filehandle init it should not have done.
      Now at 40.42.
    - The efs client could give enforcer hits if someone did an UnLock()
      right after an Examine()/ExNext() in just the right timing. A lock
      was freed twice and invalid memory way referenced in that case. Also
      freeing a ZERO lock could probably result in unusual behaviour.
      As all the lock handling code turned out to have some perfectly
      valid, but obscure areas from the simple readability point of view, I
      did some beautification work in addition to fixing things.
      And while this is very ugly behaviour of any application, efs
      should now be robust against "copied" locks. This last thing is
      mainly a paranoia fix triggered by my research on the exnext problem
      which started this. Now at 40.43.
    - Found some places where lock pointers were set up without a
      check for the BPTR to be ZERO. This was always ugly and is
      deadly now. The efs client is up to 40.44 now.
    - nipc should no longer try to write to sana 2 devices which are
      definitely known to be offline. This should be cosmetic though. I am
      still not clear on what is causing problems with ppp.device. But
      maybe this reduction of io helps finding the actual problem. Now at
      40.27.
    - After some thought I decided to modify the sana 2 device init in nipc
      to complain loud on any problems. I assume now that the user wants
      those devices she specified in Network Configuration to work well.
      Previously only a failure to open a device at all caused an
      requester to pop up. Now any "fatal" error which will prohibit nipc
      from setting up and using a device will generate a requester. This
      should reduce the "doesn't do anything after boot" problems
      without user notification by about 100%. And it should help fix
      bugs as you will get to see an error number. nipc.library is now
      at 40.28.

    - The EFS client returned ERROR_WRITE_PROTECTED instead of
      ERROR_DISK_WRITE_PROTECTED on an active ACTION_WRITE_PROTECT.
      This is fixed now and the EFS client is now at 40.45.
    - Bumped some versions to allow for a decent HWGRCS version freeze
      for release. I was unfortunately lazy sometimes. No change in
      functionality at all. Just a recompile with a new version number.
        filesystem.service:         40.32
        Filesystem Imports:         40.11
        Filesystem Exports:         40.9
        nipc.library:               40.29
        envoy.library:              37.21
        services.library:           40.2
 !! - I have a hunch concerning the ppp.device problem. It is now
 !!   possible to disable ARP by setting the ARP type to the IP type.
 !!   It counts as unsupported hack, though. I am not sure it will stay
 !!   that way. This does not affect compatibility as it is a normally
 !!   illegal combination of values anyway. Maybe ARP was the problem.
 !!   If this was truly the problem, we need to either document this
 !!   way to turn off ARP or find a more intuitive way to do this
 !!   for the user. Hmm. What about an ARP type of 0 to turn off ARP?
 !!   Hmm. Let's wait on feedback. nipc.library is now at 40.30.
    - The list of services was not correctly locked by nipc during an
      inquiry. This could lead to overwritten memory, crashes or similarly
      nasty things when the list changed at just the right time while an
      inquiry was active. nipc.library is now at 40.31.
    - The host requester in envoy.library had rather high stack usage. This
      should be better now. It could also mess up the system if you
      specified to many matchtags. This should be better, too. Now at
      37.23.
    - Filesystem Imports had rather high stack usage, too. It also
      allocated a VisualInfo and never ever freed it. Now at 40.12.

 !! - Ok, this is it. The IMHO last change before releasing Envoy 2.0.
 !!   The official way to turn ARP off is to set the ARP type to 0
 !!   now. nipc.library is now at 40.32.
 !!   Not all sana 2 drivers can transmit ARP packets. ARP is
 !!   usually useful on Ethernet, and maybe on ARCNET or amoknet.
 !!   For other sana 2 devices, refer to the respective documentation.

    *** RELEASE OF ENVOY 2.0, X-MAS 1994 ***

    - nipc/route.c: There was no release function for routes found with
      Route(). So DeleteRoute() would not work if a route had ever been
      used. The route hash value function seemed somewhat messed up.
      NetMask() called NetNum() for nothing. AddRoute() could return
      garbage or lose memory.
      nipc.library is now at 40.33.
    - Network Configuration could crash if the user reloaded the prefs
      while a device/realm/route was currently selected in a listview.
      Now at 37.14.
    - This is a fix for a documentation bug in this FixedBugs file up to
      now: "Thanks to Ralph Babel for his Guru book and some good hints on
      certain things.". Good enough, Ralph? ;^)
    - There is a bug within the ExAll() handling of BABELCDROMFS 1.2
      that really makes Envoy barf bad if you export a CD-ROM drive
      using this file system. Nothing I can do about it. Ralph Babel
      is working on a fix. It is probably out already for some time
      when this text is seen in public places.
    - The Host requester had no default position on screen. So if the
      application using it was not specifying a position, anything could
      happen. The default position for all envoy.library requesters is
      now centered on screen. If you have any idea on how to neatly
      keep the last position/size in ENV[ARC?], tell me. Any input
      welcome. envoy.library is now at 37.24.
    - The printer import prefs tried to close the accounts.library
      even though it never opened it. It also used a screen pointer
      that could have been NULL. Printer Import is now at 40.4.
    - accounts.library should no longer do unnecessary $4 accesses.
      Using a central accounts server should be possible. Finally.
      Set the environment variable "Envoy/AccountsServer" to the
      appropriate host name, and all account management should be
      done by Accounts Manager on that host. If the connection fails
      for some reason or times out after 5 seconds, there will be a
      couple of retries before accounts.library gives up. Note that
      this should finally get rid of the distributed accounting file
      mess. You should set up Accounts Manager on _one_ machine only
      and run account management there. accounts.library is now at
      37.7.
    - The printer import prefs should look a lot better now for non
      topaz 8 setups. Printer Import is now at 40.5.
    - The printer export prefs had pretty much all the problems of the
      import prefs. There was also a memory loss. Printer Export is
      now at 40.4.
    - Pretty much all the printer stuff uses a common include file now for
      the common things. Except for the client. The client needs to be
      rewritten from scratch. When I get around to do the rewrite,
      hopefully Envoy will be useful to do local print spooling without
      extra hacks! This is all in the future, though.
      printerimport is now at 40.6, printerexport at 40.5, and the
      printspool.service is at 40.6.
    - The autodoc for UserRequestA() was messed up. envoy.library is now at
      37.25.
    - While reworking the printer import/export prefs, I messed up the WB
      startup of these tools. Fixed now. Printer Import is at 40.7 now,
      Printer Export at 40.6.
    - It seems that my accounts.library work is by far too little to
      fix the problem. I even found a bug in the EFS server. If a list
      of available mounts was requested and no mounts for an
      acceptable user/pw combination were found, the server rejected
      the user instead of returning with an empty list of mounts. The
      EFS server is now at 40.33.
    - The accounts.library part in all of the management should be ok
      now. The library will open even for no server connection as a
      server may be available at any time on a retry. No more panics
      should happen if the server link breaks for some reason.
      The library base was messed up, too. There is still some work
      necessary on all the other modules related to account
      management. accounts.library is now at 37.10.
    - The realm and routing panels, and adding a device in Network
      Configuration worked basically by accident only. The gadget functions
      were using a taglist without a trailing TAG_DONE. Network
      Configuration should be smarter about adding devices now. At least it
      tries to check if the device is a SANA-II device before adding it.
      There was also the possibility that an asl requester was not freed.
      Network Configuration is now at 37.15.
    - For some reason unknown to me the IP protocol number used for the RDP
      implementation has always been off by one. According to RFC1060 it
      should be 27, and it has always been 26. Fixed. There was also an
      interesting problem with subnet masks. Subnet masks are in essence
      and very informally put a "larger" netmask, i.e. based on the
      standard net mask an ip address has, they define additional bits
      taken from the host part of the ip address to be used as subnet for
      routing purposes. This also means that in any reasonable subnet mask,
      all the bits of the netmask for the relevant ip address need to be
      set anyway if the sub net mask should be used as "better"
      replacement for the net mask which nipc does. nipc.library will now
      make this happen if the user failed to specify the netmask bits in
      the subnet mask. Network Configuration might do more checks in the
      future. Routing and realms did not work well together due to wrong
      handling of network masks for devices not using the subnet mask and
      wrong handling of source addresses. This could have caused a loss of
      information about the network on an NIPCInquiry() call and possibly
      an Enforcer hit for a certain mostly useless nipc configuration. All
      of this is a sensitive area, so it needs lots of testing.
!!    Note: This nipc.library is not backwards compatible due to the
!!    protocol number change!
      nipc.library is now at 40.34.
    - SANA-II R2 S2_PacketFilter is now supported by nipc. The private
      AS225 communication hack will only be active if AS225 is installed
      and the device in question does not support SANA-II R2. It should be
      possible now to use e.g. AmiTCP 4 and Envoy on the same S2R2
      complying device driver without having to fiddle with packet types.
      nipc.library is now at 40.35.
    - The Filesystem Export configuration editor created an empty
      configuration file instead of at least a valid IFF FORM when no
      exported volumes were set. The server did not accept this empty
      file as valid configuration and did not update its configuration
      accordingly. Filesystem Exports is now at 40.10.
    - The EFS server did not accept an empty IFF FORM either. It is
      now at 40.35.
!!  - nipc.library should pick up configuration changes to the realm and
!!    route panels via notification. It won't pick up changes to the device
!!    panel and there are reasons for this behaviour. Note that you should
!!    know what you are trying to do when you use this. nipc.library will
!!    simply take out the old realms and route configs and put in your new
!!    selections. This might affect ongoing stuff and you might loose
!!    packets. TEST THIS, PLEASE! nipc.library is now at 40.36.
    - To support the change mentioned above, Network Configuration now has
      a "Use" gadget. Remember: "Use" won't work for the device panel! Not
      much I can do about this inconsistency right now. Network
      Configuration is now at 37.16.
    - nipc.library left a resolver port lying around on exit. It also used a
      strange and dangerous seglist splitting hack on cleanup. This is
      fixed now and a decent shutdown is done. packet filtering should work
      well now with my new version of my a2060.device. Quite a few changes
      to how the resolver handled ip addresses. This was not exactly ok.
      While doing this I had to relayout the routing code. So we might have
      a ton of problems now. TEST ROUTING, REALMS, AND MULTIPLE PROTOCOL
      STACKS, PLEASE! For this nipc.library, you will have to upgrade my
      a2060.device to at least 40.6. Unfortunately the old version had bugs
      in packet filtering which would not do nice things. nipc.library is
      now at 40.37.
    - The requesters in envoy.library could leave a VisualInfo unfreed.
      They also did not return failure when they could not be opened for
      some reason. The autodocs were not exactly correct either and I
      added Window and OptimWindow tags to all of the requesters now
      to make it easier on the user. The layout code is not yet
      optimal, but it's getting better. envoy.library is now at 37.27.
    - Filesystem Exports did not free the VisualInfo it obtained.
      It is now at 40.11.
    - Filesystem Imports uses the new envoy.library tags now. This should
      give visually very attractive results when envoy.library is done.
      it is now at 40.13.
    - Users and Groups behaved rather different in some areas. They
      should both look and behave similarly now. Also the name gadget
      is activated when you create a new user/group and they both
      handle the AccountsServer hopefully correctly! They both used
      standard gadget calls on gadtools gadgets and did not correctly
      handle the listview updates. Users is now at 37.16. Groups is
      now at 37.14.
    - ICMP handling in nipc.library could leave a buffer lying around if no
      route for a packet could be found. The packet filtering should work
      better now and will hopefully avoid unnecessary CPU load when
      multiple protocol stacks are in use. Memory handling for all
      the buffers should be more unified and straightforward internally
      now. Some internal caching code for the buffer handling should speed
      up memory handling a little. Memory use has increased a little.
      nipc.library will now clean up any pending resolver messages on exit.
      It used to simply delete the internal port which cause a delayed
      crash when the pending message finally returned after the
      library was gone. Handling transactions should be more robust
      when the user passed garbage input. nipc.library is now at
      40.39.
    - Printer Import now blocks the main window on using envoy.library
      requesters. It is now at 40.8.
    - Printer Export now blocks the main window on using envoy.library
      requesters. It is now at 40.7.
    - The Accounts Manager did not handle tool types parsing for WB
      startup correctly. There was a potential memory leak. I
      intentionally changed the WB argument parsing a little. Only the
      tooltypes of the program itself will be checked, not those of
      any project icon used. It helps updates and installation to have
      a project icon instead of the real thing in SYS:WBStartup and
      maybe in some other places. But it for sure doesn't make sense
      at all if due to wrong configuration the manager picks up
      different database files for different project icons. It also
      forgot to free memory on exit. Accounts Manager is now at 37.15.
    - Services Manager lost memory on exit. It is now at 40.3.
    - I created to simple project icons for the managers which will be
      used to startup them via WBStartup. I still have to change the
      install script to support this, though. The default place for
      these icons are the manager's directories. They'll be copied to
      WBStartup by the installation and can be copied to arbitrary
      places by the user. This should finally stop the "multiple
      managers floating around" problem.

    - With this update to the EFS client, the 2.04 C:Info should work
      again. I overlooked a suggestion in the (great) Guru Book. Sorry. The
      client is now at 40.47.
    - If accounts.library completely failed to contact the host listed as
      server, it will reevaluate the server name on the next command. This
      is to give the user a chance to correct typos in
      ENV:Envoy/AccountsServer on a running system without a reboot.
      accounts.library is now at 37.11.
    - The EFS server will now use an input handler to check on disk
      changes. I did this to get rid of the excessive locking done to
      detect disk changes. It should have done it like this all
      along. Note that the EFS server now relies on the underlying
      filesystem doing correct diskchange notification via the
      input.device queue. I also changed the server task name. The EFS
      server is now at 40.36.
    - accounts.library will only retry once to contact the server
      now. It used to do this three times. With internal nipc.library
      handling of retries this time added up considerably without any
      real use. accounts.library is now at 37.12.
    - Another change to password hook handling. It still didn't work
      quite right it seems. envoy.library is now at 37.28.
    - Used the same hook code in Users now. Users is now at 37.17.
    - Network Configuration should no longer loose the realm server
      name/address when use of a realm server is turned off. Please
      check if this affects nipc.library in any way. It shouldn't, but
      who knows where bugs hide. Network Configuration is now at
      37.17.
    - The password edit hook really gets on my nerves. Now, it should
      finally work better. "Finally"? Hah! Data vu. Let's wait and see.
      Exiting the login requester via TAB is no longer possible.
      envoy.library is now at 37.29.
    - Same password hook change to Users. Users is now at 37.18.
    - Groups will now resort the listview on a group name change.
      Groups is now at 37.15.
    - Printer Export had a mungwall hit on adding a group. It is now
      at 40.9.
    - nipc.library should now recognize its officially assigned UDP
      port number and filter all other packets. There was also another
      routing problem within the resolver code for realm servers.
      nipc.library is now at 40.41.
    - I think I found the cause for spurious "Can't connect to host
      bla" messages. FindService() wasn't really geared up to handle
      multiple simultaneous calls and would return failure in this
      case. services.library is now at 40.3.
    - Network Configuration accepted owner names > 31 characters in
      length even though it couldn't handle this (i.e. crashed) under
      certain circumstances. Realm name gadgets weren't handled correctly
      either for input >19 characters. Network Configuration is now at
      37.19.
    - On loading the current work prefs, Network Configuration freed any
      and all old prefs, even the initial ones. It also did not update the
      display correctly. It is now at 37.20.
    - Services Manager did not free the list of services correctly on exit.
      It would not even not free the list correctly. Actually, I don't know
      why Services Manager did not crash on exit. Magic? Who knows. Anyway,
      it is now at 40.4.
    - ACTION_FH_FROM_LOCK has been broken again since I introduced
      RMS due to a really dumb single character typo. The EFS server
      is now at 40.37.
    - Slight rework to the mount handling in Filesystem Imports. If I
      get around to implement a better mount name handling this should
      help. As a positive side effect of the work the listview is now
      sorted alphabetically. Filesystem Imports is now at 40.14.
    - I learned something new about the AS225 backdoor. When Envoy
      connected to AS225 through the backdoor, all packets _had_ to go
      through this hack internally and the multiple protocol stack
      support of a device driver would be ignored. Ugly, really ugly.
      As we have SANA2R2 complying device drivers for both ARCNET and
      Ethernet and packet filtering support in Envoy, I took out the
      backdoor completely. Less code and a little less overhead.
!!    Note that you have to use SANA2R2 compliant device drivers now if you
!!    want to use Envoy and AS225 together.
      I also removed an ancient paranoia hack related to the
      CopyFromBuffer() implementation used for communicating with S2 device
      drivers. I also changed the CopyFromBuffer() and CopyToBuffer()
      implementations to work a little better. Please tell me if you
      encounter any problems with AS225 or derivatives thereof or any
      device driver out there. nipc.library is now at 40.43.
    - The EFS server could pass a ZERO lock to an Examine() it used.
      While this should not be harmful, it turns out that it can be
      harmful. I am kludging around problems in other people's SW
      here. filesystem.service is now at 40.38.
    - It happened once in a while that the EFS client returned
      ERROR_OBJECT_NOT_FOUND on previously valid file handles or locks.
      This is an indication that they could not be reestablished after a
      network failure for some reason. Even if the server and the
      networking hw works correctly it could happen that locks or fh's
      could not be reestablished because when they were initially set up,
      some path information about the server location was not checked. Now
      locks/fh's won't even be created by the EFS client if this necessary
      path information cannot be obtained. EnvoyFileSystem is now at 40.48.
    - Some cleanups and link rearrangements done to nipc.library. Took
      out a few obsolete lines and moved some code around. No bug fix
      of any kind and I hope I did not introduce any. Please do some
      diskspeed tests with all sorts of hardware. Packet filtering
      slowed down nipc somewhat. I am thinking about adding some sort
      of option to completely turn off packet filtering for the power
      user who doesn't use Envoy together with some other protocol
      stack, but I need more input on this topic first. nipc.library
      is now at 40.44.
    - nipc.library versions beyond 40.45 will be able to do packet
      filtering depending on the settings of the new Network
      Configuration gadget to turn packet filtering on/off. Default is
      "on" and the power user can turn it off whenever she/he wants.
      Note that the locale catalog had to change for this! Network
      Configuration is now at 37.21.
    - envoy.library had severe startup problems. Anything beyond one open
      was hazardous. Any failing open would crash the system. Any close on
      a system with >= OS 2.1 could jeopardize stability. Expunge wasn't
      safe or correctly done either. Interesting enough I needed a 2.1 test
      setup to actually reproduce the problems. 3.1 would pretty much
      handle it great even with those bugs. Special thanks to Dave for
      locating the source of trouble. envoy.library is now at 37.30.

About here I froze the 2.0b patch.

    - nipc.library had a bug which would mess up an expunge. This should be
      fixed now. Cleaned up some sources to make them more readable
      and once again changed the resolver handling of realm server
      queries. Also evaluates the packet filtering config flag now.
      nipc.library is now at 40.45.
    - The EFS client will now use unique volume names by appending a
      decimal number to the name if it can't use the true name due to
      a name clash. It used to do a time stamp hack. It is now at
      40.49.
    - Some changes to nipc.library. If you tried to delete an Entity
      that had not been lost by all remote users yet, you would be
      left with an unusable entity that you could not get rid of. This
      should be fixed now. The resolver should handle multiple remote
      realm entries for one realm correctly now and due to some
      heavy magic, there is a good chance that PPP connected hosts can
      be added to a realm now without any hassle. The trick is not to
      specify the PPP connected host via its subnet in "Local Realms",
      but with its IP address in "Remote Realms". This is really heavy
      magic! nipc.library might be slightly faster now. Hmm. We'll
      see. nipc.library is now at 40.46.
    - The EFS server will now use the baselock instead of a ZERO lock
      to get the volume name for an RMS export. It also will no longer
      try to use any export path that refers to a file. All of this has
      subtle consequences affecting only those users that do not have
      correct configurations. filesystem.service is now at 40.39.
    - I hacked away on the printspool.service to test some new
      concepts. Printing is done differently now. All printing is done
      on the Amiga where printer.device has been opened. This has not
      changed. The raw data stream is then rerouted via
      envoyprint.device to the printspool.service on the configured
      print server. This works even for the server machine now! The
      printspool.service will put this data to the configured
      underlying device (parallel/seriell or PUNT prefs if configured)
      and do its own timeout handling including a raw "nag" requester.
      Note that PUNT in the service config cannot currently be set via
      the prefs editors. So you can test this only with
      seriell/parallel. The setting will be taken from the current
      printer prefs on the server. Again, this is just a hack to test
      some new concepts. A final printspool.service would do some
      things in a different way. Actually all of the printer stuff will
      probably look different, but the current stuff is good enought to
      test things before really getting into a rewrite. Oh, the
      printspool.service timeout for outgoing data blocks is currently set
      to 30 seconds. printspool.service is at 40.8.
    - The EFS server will switch to an ExAll emulation via
      Examine()/ExNext() now if
        a) it finds a C= filesystem with known ExAll bugs that can't
           really be handled safely.
        b) the user sets a flag in the export config (which is not yet
           implemented there)
      Thanks to Ralph for some hints on what is wrong with ExAll().
      filesystem.service is now at 40.40.
    - Filesystem Imports will now put permanent mounts into
      SYS:DEVS/DosDrivers instead of DEVS:DosDrivers. This should help
      on booting machines where the DEVS: assign has been changed.
      Filesystem Imports is now at 40.15.
    - A new member of the Envoy family has been born after a ~24 hour
      pregnancy of my A3000: Envoy_port-handler. It will replace the
      standard port-handler to allow for redirection of SER:/PAR: in
      case of network printing. This is needed for dumb SW like
      FinalWriter which insists on using SER: or PAR: for PostScript
      printing. Currently the handler does not have this redirection
      feature yet because I need to redefine the import prefs first.
      Features it has compared to port-handler 40.1:
        - timeout requester on SER:/PAR: after 30 seconds.
          This is currently for debugging, but it could be refined
          and localized. Issue: How to configure the timeout values?
          Via the printer import prefs? This works even without
          Envoy so this might be the wrong place. Hmm.
        - Correct results for Seek and SetFileSize packets.
        - Should not barf on multiple queued packets.
        - PAR:FAST and PAR:SLOW to set those bits.
        - PRT:TRUERAW to use PRD_RAWWRITE instead of the Escape
          sequence.
        - Does not do a Stricmp() on BSTRs or BSTR checking without
          taking the length into account.
        - Does not skip allocation checks on startup.
      Note that most of the above is yet untested. Please test the
      "SER:baud/bla" specifications and similar stuff in depth if
      possible. This testing is really important. We can't have bugs
      here! [Oh how I wish port-handler had been converted to use a
      GlobVec != 0 for >=2.0 in spite of all those 1.3 disks out
      there.] This first test release of Envoy_port-handler has been
      frozen at version 42.4.
    - Enforcer hits on large read/writes with transfer errors made me look
      very hard at nipc.library again. I found several places with
      inadequate semaphore locking of shared structures. I also
      rewrote some rather strange loops. Lots of cleanup changes to
      the transaction/entity code. As a positive side effect,
      transaction handling should be even faster now. As I
      cannot reproduce the hits myself even though it was possible to
      identify at least one possible cause, I can only hope you
      really, really, test this! nipc.library is now at 40.47. I hope
      it works well.
    - Along the way I changed the general compiler option files for all
      of Envoy. This gives better results overall, which justifies this
      major change. A full rebuild will come along eventually. The
      betas will pick up this change automatically.
    - nipc.library still had a very strange connection to
      services.library. I removed this code. nipc.library is now at
      40.48.
    - The counterpart in services.library has been removed, too. There
      was also a bug in the failure path of open code. services.library
      is now at 40.5.
    - Some strange version mixup with Services Manager. To be on the
      safe side I bumped the version and rebuilt it. Services Manager
      is now at 40.5.
    - Filesystem Exports now uses a cycle gadget to set the security
      options. The left over checkbox gadget has been turned into a
      'no ExAll()' flag to support filesystem.service >=40.40. Note
      that the catalog had to change for this, too! Filesystem Exports
      is now at 40.13.

    - envoyprint.device is now sending a sequence number with every
      transaction. This is of course not backwards compatible, but
      even envoyprint.device will be replaced eventually anyway. I
      need this for testing of the new server stuff. envoyprint.device
      is now at 40.4.
    - The cycle gadget in Filesystem Exports has now the "correct" height.
      The listviews will be sorted alphabetically now. Filesystem
      Exports is now at 40.15.
    - The hunt for bugs in nipc continues. Ralph found some ugly enforcer
      hits and memory list screw ups that occurred under (IMHO) heavy
      transfer load. When looking at them it turned out to be a totally
      timing dependent problem. I could not reproduce it myself, but I
      found two possible causes and fixed them. I'd need a darn fast
      machine, a special networking setup, and task switches at just the
      right time to reproduce those bugs. nipc.library also released a
      semaphore it never obtained on some failure path and one of the
      internal copy functions was really broken. Fixing the last thing was
      cosmetic though, as the broken part is currently not used anyway. For
      this release of nipc.library I disabled the use of memory pools which
      results in a slow library that is easy to debug. All allocations will
      go straight to AllocMem and I ask you to run mungwall with periodic
      "munglist check" runs to find problems immediately, not only after a
      whole memory pool got screwed up. If you find any memory trashing, I
      would need a dump of the memory regions in question in addition to
      all the hit and/or alert messages with segtracer hunk info if
      possible. This debugging release of nipc.library is at 40.49.
    - filesystem.service had a few bugs. For full security logins with
      an "other" user, it returned messed up protection bits under
      certain circumstances. This should be fixed now. I still have to
      fix the "rename security" and "reconnect while deleting" bugs.
      One step at a time though. filesystem.service is now at 40.41.
    - Bugs always turn up in amounts well > 1 after nothing has happened
      for a long time. The "reconnect while deleting" bug was due to a race
      condition on reconnect that also affected "notification maintenance
      on volume removal". Both usually lead to an instant death of the
      server. The "rename security" bug was only part of the problem.
      SetOwner and SetProtection were affected, too. Please test security.
      There also was a potential problem with memory loss when a broken
      prefs file was read in. The server side now tries to compensate
      for the V36/37 Seek() bug, too. filesystem.service is now at
      40.43.
!!  - To test the fixes for the server security handling, I made an
!!    internal enhancement to the EFS client. While doing this I found a
!!    potential problem in the Seek() handling that could cause strange
!!    results when a reconnect or relative seek followed a failing seek. As
!!    a positive side effect of the work I did on this, a Seek(fh, 0,
!!    OFFSET_CURRENT) should be _fast_ now. Please test seeking, including
!!    failing seeks in all directions and modes in detail. Please, please,
!!    please! EnvoyFileSystem is now at 40.50.
    - nipc.library has seen major analysis work now. I found and fixed two
      bugs with the RDP management. It would accept packets on closed
      connections and happily leave the buffer lying around that contained
      the RDP packet that caused a connection to close.
      There was a timing hole where transactions buffers could have been
      freed twice on a fast machine. Also there have been tons of changes
      to the Entity system already. Losing and deleting entities wasn't
      always safe. Except for the RDP problems, all the other stuff
      dates back to the 1.x days. Just a few lines of comments here, but
      MAJOR CHANGES INSIDE. nipc.library is now at 40.50.
    - nipc.library should no longer give enforcer hits after
      filesystem.service hasn't been accessed over a remote link over 30
      minutes. nipc.library is now at 40.51.
    - Still a problem with notification handling due to the changes to get
      the async delete fixed. Also the dead mount timeout handling was
      strange now. The EFS server simply killed any mount that hadn't been
      used for 30 minutes. Now it will kill this mount only if the client
      can no longer be ping'ed. The client needs to reconnect in this case!
      filesystem.service is now at 40.46.
    - Another one "bytes" the dust. Reconnect to a mount on a subdir,
      not on a server root, didn't necessarily do what you expected.
      The server "just said no". filesystem.service is now at 40.47.
    - Cleanup on the EFS client. It is LIBCODE now! EnvoyFileSystem is
      at 40.51.
    - I just stumbled over a strange SAS bug. GO inlining of a single use
      static function (which is called via a cast as LIBCODE __asm with A6
      as paramater!) by using OPTINLOCAL messes up the A6 passing. Guru.
      Simple work around. Don't make the called function static so it
      won't get inlined or declare it as __asm to avoid inlining. Thanks
      for the hint, Steve! EnvoyFileSystem is now at 40.52.

    - Fixed a problem within the EFS server. The check to avoid an import
      of a file instead of a directory was a noop due to a missing line of
      code. filesystem.service is now at 40.49.
    - If a connection died, nipc would try to release a semaphore that no
      longer existed. nipc.library is now at 40.53.
    - nipc.library could overwrite buffer memory if Entities were created
      while a network query was in progress. A slight change to
      transaction handling should reduce memory fragmentation. Reenabled
      pools as they don't seem to cause problems at all. Disabling didn't
      help finding problems either. So I might as well use them again and
      reduce fragmentation this way. nipc.library is now at 40.54.
    - The client will do a check now if a lock is freed twice.
      EnvoyFileSystem is now at 40.53.
    - Reworked a2060.device because it wasn't flushing correctly and
      had a potential problem with multiple protocol stack use. The
      flushing bug got in my way on nipc testing, so I decided to do
      some work here. BTW, it should spend _less_ time in Disable()
      than the original C= device. It might spend more time in a
      soft interrupt though, depending on the load of incoming data. My
      a2060.device is now at 40.8.

    - The "No ExAll()" gadget in Filesystem Exports couldn't be used due to
      a bug in the gadget code. Gadget sizes should be correct now,
      too. While doing this, I also killed the obsolete startup code.
      Filesystem Exports is now at 40.18.
    - A few more fixes to the WB startup handling of Filesystem Exports. It
      is now at 40.20.
    - Services Configuration now has a "Use" button. I should have
      done this for 2.0. Oh well. The gadget sizes match common usage,
      now. The listview should appear sorted now. Services
      Configuration is now at 37.15.
    - There was a bug in the filesystem.service that really messed up
      closing the service with CloseLibrary. A garbage seglist value
      could have been returned which would pretty much trash the
      system right away. I introduced this bug at 40.42 when I
      replaced the old library handling code. filesystem.service is
      now at 40.50.
    - Network Configuration should now have a correct english title,
      standard gadget sizes, and sorted listviews. Network
      Configuration is now at 37.22.
!!  - I made an important change to the Accounts Manager enhancing
!!    security. User and Group information will now be written out in
!!    encrypted form. Conversion of old, unencrypted information is
!!    automatic on the next database change. So if you want to have your
!!    database encrypted, just add and remove a dummy user/group to have
!!    the database written to disk. Accounts Manager is now at 37.16.
    - My fix for reconnect on files in EFS messed up Lock() of a file
      and Open(""). This should work again now. Also DupLock() should
      work on files/dirs now that do not have the execute protection
      bit set. We now have support for fixing the seek position on
      r/w operations automatically if the client supports this feature.
      filesystem.service is now at 40.52.
    - The EFS client supports handling the seek position during split
      r/w operations now. There should be NO WAY to mess up the seek
      position, even for split r/w's with network failures now, if
      the server side supports the additional info passed.
      This affects performance. Please make diskspeed tests, telling me on
      which HW combinations with which buffer sizes you experience what
      kind of performance hit. EnvoyFileSystem is now at 40.54.
    - A slight change to ARP handling in nipc.library should improve
      connection startup by reducing unnecessary traffic. I doubt it
      is measurable, though. nipc.library is now at 40.55.

    - Async R/W handling inside the EFS client was broken. it could
      reply twice to a single packet which would crash the machine.
      EnvoyFileSystem is now at 40.55.
    - The Accounts Manager encryption messed up all the admin flags.
      Accounts Manager is now at 37.17.
    - Due to stupid US laws Accounts Manager doesn't really do any
      encryption anymore. It just uses ROT13 now. Accounts Manager is now
      at 37.18.

    - Filesystem Imports had a very strange bug in doing string
      parsing. If the locale.library base was just on a 256 byte
      boundary (i.e. the low byte of its address was 0 or if it
      wasn't installed!), one could not really mount anything.
      This in effect makes it impossible to use it on V37. Ouch.
      Filesystem Imports is now at 40.17.
    - Due to a memory allocation without MEMF_CLEAN and a missing
      preset, any internal volume structure created by the EFS
      server was no longer freed, even if it was unused.
      filesystem.service is now at 40.53.
    - envoyprint.device never freed returning transactions. Ouch. While the
      functionality is pretty much what I need for the new printing system
      now, I'll most likely do a rewrite eventually to make this nice and
      shiny. envoyprint.device is now at 40.5
    - accounts.library had a problem in the expunge code. This is fixed
      now. accounts.library is now at 37.15.
    - services.library had a problem in the expunge code. This is fixed
      now. services.library is now at 40.7.
    - nipc.library took an invalid shortcut to IP handling for any
      local packets to be sent out. These packets will now be handled just
      like any other packets via the general protocol input handling. In
      general there was the strange assumption that an IP packet must have
      a fixed header length. Of course this would have killed any
      "advanced" setup. The changes should have reduced the overhead in
      processing packets a tiny little bit. The protocols shouldn't fiddle
      too much with IP packet headers any longer. This can count as pretty
      major change. The UDP code will now do checksum tests, too. There was
      a potential problem in IP address handling of packets that were sent
      and received locally only. IP packets that may not be fragmented will
      not be fragmented now. Route hashing should now be a little better.
      There was also a cosmetic problem in the resolver code which
      incidentally did not crash anything. I cleaned it up anyway.
      Registered IP protocols are now checked according to their
      "priority", e.g. RDP is more important than UDP for Envoy, so
      an incoming IP packet will be tested for RDP before UDP. ICMP
      currently is the lowest priority, i.e. it will be checked
      last. This should help efficiency in packet processing. The
      IP layer should now pass on and filter options in the packet
      header correctly. netprobe showed me an interesting autodoc
      deficiency while debugging all of the above. I added an
      important note to the NIPCInquiryA() autodoc. There also was an
      interesting problem in the Expunge handling of this library which
      could potentially affect system stability. Usage of the
      LIBCODE getreg hack has been reduced by a fairly simple but
      basic change. This made the code slightly better and reduced
      the compiler dependency. All of the above counts as
      intermediate step. Full ICMP functionality is still missing.
      nipc.library is now at 40.56.
!!  - The RDP checksum handling was messed up. I wonder how this
!!    worked at all. Fixing this makes RDP work according to specs
!!    of course. nipc.library is IMHO once again incompatible to
!!    previous versions. I also added a missing initialisation for
!!    dataless packets to the RDP code. This could have caused
!!    strange retries. nipc.library is now at 40.57.
!!  - To be RFC compliant in its IP handling, nipc needs a new flag
!!    "Is Gateway". This cannot be determined from the current
!!    settings. I updated Network Configuration to include a gadget
!!    for this. Note that the catalogs changed for this! Old
!!    configurations will default to a NON GATEWAY setting. This
!!    is less dangerous and in most cases does the correct thing.
!!    It will also finally handle the case where the extra realm
!!    panels/gadgets are displayed and the user reverts to a no
!!    realm config via the menu. Network Configuration is now at
!!    37.23.
    - I started adding use of the gateway flag to nipc.library.
      Finally, I will be able to complete ICMP handling inside nipc
      because of this, too.
    - EnvoyFileSystem could still get mighty confused on async R/W
      packets. Heck, it could even get confused on packets in sync.
      It will no longer force a reconnect if a R/W failed because
      of a low memory condition. I also reworked the retry
      handling. It's hopefully continously getting better and more
      straightforward. It was a mess with a zillion failure paths.
      There also was a bug where a failed R/W could get the client
      into an endless loop. The client would also happily retry
      already aborted R/W actions. For a failed ACTION_END, the
      internal file handle would not always be cleaned up
      correctly. I should split up client.c. It is about 4 times
      that size that is IMHO acceptable for a source file when I
      count the lines. But if I split it up, the optimizer cannot
      do such a great job. :-( EnvoyFileSystem is now at 40.56.
    - There was still at least one retry problem that could cause
      requester suppression. The retry count will now be reset
      whenever a successful connection has been made and whenever
      a requester popped up because of a failure. I also
      implemented ACTION_INHIBIT. Not that it makes a fat lot of
      sense, but I noticed that Workbench uses Inhibit() for a
      nasty internal hack. So I implemented the packet. I didn't
      really test it yet! It actually doesn't help Workbench either
      as the nasty hack wants to see a true exec device name inside
      fssm_Device. The EFS client doesn't have this of course. It
      might come in handy for testing though because ACTION_INHIBIT
      will only shut down packet processing and volume list
      updates. Internal client activity should proceed as usual. It
      is not a packet that is put through to the server. That
      wouldn't make too much sense anyway and it would only confuse
      things. The client could happily clean up a volume node even
      if there were still pending notifications. I also put in
      basic ACTION_DIE handling for easier testing. Note that
      ACTION_DIE is not supported in general because there is no
      real safe way to implement it. If you don't know exactly what
      you are doing with it, you will most likely cause a nasty
      crash! Async R/W's still didn't work. There were several
      problems in the handling of returned R/W transactions. Thanks
      to the awful lossiness of AmigaLink ;^), I could easily test
      this without artificially creating major networking setups.
      Just try a "LIST DF0: ALL" with AmigaLink to disrupt network
      transfers nicely. A sneaky method to test the stuff with
      fairly reproducible results. I never thought that this would
      actually come in handy. Kai, I hope the device open/expunge
      will be fixed soon, too! If large R/W's fail due to network
      overload, the machine should finally no longer die a slow
      reconnect death! Also the machine will not unnecessarily
      reconnect for aborted old R/W transaction any longer.
      Downtimes on overload should be reduced. The R/W changes
      probably affect performance a little. The overhead for every
      single R/W has been and still is noticable, the overhead if
      one R/W needs to be split (which currently happens for
      requests > 32KB) is not that bad. At least a R/W will
      _always_ be at the correct seek position with the current EFS
      client/server. This hasn't always been the case. If you see a
      noticable performance problem that you can back up with
      numbers, I might put some extra work into the problem.
      EnvoyFileSystem is now at 40.57.

    - Even more changes to EnvoyFileSystem R/W and reconnect
      handling. Every R/W should now have one less AllocMem/FreeMem
      combination and therefore one failure path less.
      Previously, the dynamic delay feature to compensate for slow
      networks was only used if a reconnect failed already once.
      Now it will be used if a transaction times out which IMHO
      makes more sense. The old style could cause a

        FOREVER
        {
            handle some packets
            handle a packet with a transation timeout
            reconnect successfully
        }

      cycle without any timeout correction. The new cycle will
      increase the dynamic delay before trying to reconnect. We
      also do another stunt to avoid a reconnect. On the first try
      to reconnect, we ping the current destination. If the ping
      was successful, we simply keep the connection. This will
      happen only on the _first_ try to reconnect for a failed
      transaction and should catch isolated timeout occurrences
      due to network load. By not doing the ping on succeeding
      tries, we avoid successfully pinging a dead
      filesystem.service forever. All of this is to avoid
      unnecessary reconnects which are essentially identical to
      remounts including all filehandles, locks, etc.
    - The PingEntity() function in nipc.library was broken. It did
      not handle limit values >= 1 second well and maybe even
      confused timer.device. nipc.library is now at 40.58.

    - The EFS reconnect handling is a nasty thing on both sides.
      While checking all of this I found a bug in the debugging
      shutdown code of the server which prevented a restart without
      flushing it out of memory. Finally the Server should truly
      generate unique ID's for identifying mounts. Previously it
      used the memory address of internal mount data which could of
      course be identical on a reboot. This could have confused the
      client really bad and possibly crashed the server. Now it
      uses the current system time when creating the mount with a
      little additional magic. This should be a better unique
      value, based on the assumption that on a halfway decent
      server we have a halfway decent clock. The server check when
      to discard unused mounts no longer uses PingEntity(). That
      means the server won't block anymore for a few seconds when
      it tries to detect a bad mount. After a mount has not been
      used for 30 minutes, the server will now send out a dummy
      diskchange notification to the client. The client won't act
      on this in any major way if the volume information did not
      change in the meantime. If the client's response comes back
      to the server, the server will restart its "unused" timer.
      Otherwise it will assume that the client is dead and kill the
      mount. The server used to return a "user reject" error if it
      couldn't find a mount for a packet. It will return a "no
      mount" error now which is IMHO a lot more appropriate.
      filesystem.service is now at 40.54.
    - Reworked reconnect on the client once again. Before
      actually reconnecting, it will now try to send an
      ACTION_INHIBIT FALSE to the server. As the server does not
      implement this packet, this doesn't do any harm. If the
      transaction succeeds, we can safely assume that this mount is
      still alive. This should fix excessive reconnects because of
      spurious timeouts. PingEntity() wasn't such a good idea anyway
      as it can't check if the mount is still available.
!!    This is a DEBUGGING release with kprintf output on reconnect!
!!    Please send me sushi logs for any problems you find!
      EnvoyFileSystem is now at 40.58.
    - For testing the nipc and EFS stuff I had to chose hosts and
      log in and out of my test setup about a million times. As I
      am a A2024 user with a setup CGTimes 30/courier 18, the
      requesters of envoy.library that were only "almost" font
      sensitive really got on my nerves. The host and user/group
      requester should now pick up the system font setup correctly.
      The host requester should use a lot less stack now, too.
      I also tried to make the sizing visually more attractive by
      rmeoving the gadgets on a IDCMP_SIZEVERIFY message. It
      turned out though, that even this "do almost nothing" is IMHO
      too much for verify handling and confuses the poor user
      who wants to quickly size a window. So I took this out again.
      I guess we'll have to wait for a nice, small, fast, and
      resizable V44 gadtools ;^). Please check these major GUI
      changes for memory leaks etc. envoy.library is now at 37.32.
    - BIG problem in nipc.library. Probably since at least 40.50. I
      didn't really do research on this bug in the archives as it
      wouldn't have helped anyway. If a failing transaction
      (request or reply) only arrived in fragments due to some
      network problem, these fragments could show up in the next
      successful transaction. Hmpf. I spent tons of time on
      improving SANA, IP, and RDP handling and reworked the Entity
      chaos. What do I get? A major problem in the Transaction
      code. Why nobody noticed this before? EFS used to do a brute
      force reconnect on a transaction failure. This meant losing
      and finding the remote entity again. The brute force
      reconnect cleaned up these fragments. So while the problem
      was there, it hardly ever surfaced. Now we have a more
      sophisticated reconnect handling in EFS and the bug showed.
      Please tell me if performance is affected! nipc.library is
      now at 40.59.

    - The Network Printing tool will now handle ENV: and ENVARC:
      prefs separately when setting up or removing Envoy printing.
      This keeps current printer prefs intact if they differ from
      the saved prefs. Network Printing is now at 37.5.

    - nipc still didn't work correctly. I didn't notice it because
      I concentrated on packet loss and data messups and tested
      this with AmokNet HW. This HW can be classified as "slow",
      and for slow HW, nipc did not use IP fragmentation to keep
      overhead small. This means that I did not notice the bugs
      that I introduced in the IP fragmentation code after 40.55 at
      all. Some pointers were not always set up correctly and
      the packet ID's could be very messy at times. Ouch. I wish I
      had a spare A3k or A4k here to set up a really nice test
      environment with both AmokNet and Ethernet. Oh well. I also
      replaced some strange Forbid() handling with decent semaphore
      calls. It isn't good style to change too much at once, I
      know. This time I couldn't resist. I hate Forbid(). This nipc
      release has been tested with lossy AmokNet HW with and
      without fragmented packets by artificially affecting the
      maximum allowed data packet size. Looks good here. Yes, this
      time I actually _checked_ if fragmented packets were handled.
      Hopefully this fixes your problems on standard networks. If
      this release works for you, I'd be very interested in
      performance data. nipc.library is now at 40.60.
    - FindEntity() would not set the error information correctly in
      rare cases of network failure. The RDP code will now use a
      cache for internal retransmit information. Previously it
      allocated a wrapper per packet. Now it will allocate at
      most n wrappers, with n being the respected window size of
      the connection. The wrappers will be reused. This should
      reduce memory allocation overhead, fragmentation, and
      processing time needed fairly well. There was also some
      garbage in the RDP round trip time estimation and some stupid
      processing in the state machine. There was also a chance that
      on opening an RDP connection the nipc.library on the passive
      side of the open could free an nipc buffer twice if no
      suitable port to connect to existed. nipc.library is now at
      40.61.
    - I am really not sure what kind of problem we have with nipc
      right now. For testing I added some more paranoia checks for
      things that should never happen. There was one case where a
      ReplyTransaction() could mess up an internal counter. But
      this case would have only been triggered if there wasn't a
      free signal bit. Very unlikely and impossible with EFS. I
      doubt that it is actually the problem. The triggered error
      531 is significant for a connection that got shut down
      unexpectedly. This can happen only on _very_ severe network
      failure. Highly unlikely. I redid the library setup code to
      make debugging and maintenance easier. Hmm. The work of the
      setup code I could have avoided if I had known how buggy the
      QuickNetS2.device 2.3 is. Oh well, without a matching test
      setup and reproducible results one is just fiddling around
      sometimes :-(. I still have to investigate the sudden
      appearance of error 531. To help with this, I added even more
      paranoia checks to the transaction and entity management
      code. nipc.library is now at 40.62.
    - The IP fragmentation code was buggy. It didn't handle the
      header length well and could possibly confuse things
      depending on the packet length. My previous checks of the
      fragmentation code did not take the packet length into
      account that well. I tried to do it right this time,
      though it is tricky stuff. I wonder what kind of MTU will
      break things again :-(. The reassembly code wasn't that great
      either. I added a few sanity checks that should help find
      further problems. I had also introduced semaphore deadlock
      potential into ReplyTransaction() in 40.60 which blocked nipc
      on random occasion. This was probably the cause for dying
      connections. A semaphore stayed locked where it should have
      been unlocked temporarily. Hmm. I really need to get the
      external IP/ICMP interface done if only to be able to test
      this stuff without major setup work. nipc.library is now at
      40.63.
    - On reassembly of fragmented packets, the length of the
      resulting packet was calculated from the size of the fragment
      nipc buffers, not from the sizes set in the packet headers.
      These can well differ with e.g. the A2065 where it somehow
      seems that the minimum data link buffer size returned is 50
      bytes for some reason unknown to the SANA specs. Depending
      on the amount of data transferred this really confused
      packet reassembly and resulted in garbage data for the
      registered IP protocols. I tested this (finally) with the
      a2065.device and noticed that both the C= a2065.device 2.16
      and the inet version 3.0 (which I happened to have access to
      at the time) have deadly CloseDevice() code. As I always run
      enforcer and mungwall this stuff is a nuisance at best. I
      think I need to create an HWG a2065.device. Hmpfh.
      nipc.library is now at 40.64.
    - I had an optimization in the reassembly code that rearranged the
      order of the fragment list to reduce seek times. Somehow this
      didn't work right. So I took it out for now. I'll have to
      investigate this problem, though. nipc.library is now at
      40.65.
    - The modification to the nipc buffer size for incoming packets
      with a buffer that is bigger than the actual packet is now
      done in a more logical place. This means that I don't have to
      check for data sizes later. I also left in a paranoia alert
      and a debugging kprintf. They should tell us about problems.
      Hopefully all of this finally fixes the 531 errors.
      nipc.library is now at 40.67.
    - More nipc changes. The S2R2 packet filter support did not
      take the new protocol registering scheme into account. It
      should now react to all registered IP protocols. Previously,
      it only knew about ICMP, RDP, and UDP. Using packet filtering
      has subtle consequences for very advanced setups. Only those
      packets will be handled that nipc understands itself. This
      means that you can't use gateway functionality in a mixed
      setup with packet filtering because "unknown" IP won't be
!!    accepted, handled or routed at all. Net result: For IP gateways,
!!    turn off packet filtering.
!!    The gateway flag is finally evaluated inside nipc IP routing.
!!    Basically, this means that Envoy based machines will only
!!    exhibit gateway functionality in IP routing now, if they are
!!    configured as gateway via Network Configuration. You have to
!!    specifically TURN ON gateway functionality compared to
!!    previous versions. If your machine isn't a gateway, i.e. if
!!    it doesn't have to forward packets for other machines on
!!    different physical networks, DON'T use it as gateway.
      IP options were not processed in the copy that was sent out,
      but in the original packet. This could have messed up things
      not only for broadcasts. Local IP packets were not
      necessarily handled correctly.
      Even the complete S2R2 configuration can be updated without a
      reboot now. On a configuration change, nipc.library will shut
      down all the devices and reopen those found in the
      configuration. Note that this also (obviously) means a loss
      of any additional routes you set. In any case it should no
      longer be needed to reboot an Amiga with Envoy now.
      This might mean that you better upgrade to a2065.device 3.2
      with my CloseDevice() fixes as the old a2065.device doesn't
      shut down correctly.
      Some SANA code used a questionable setup of device requests.
      This should be fixed now.
      Note that I left in a single paranoia kprintf at the moment.
      It will be activated if the calculated packet size can't be
      successfully matched to the buffer. This should never ever
      happen anymore, but who knows.
!!    You should better update nipc.library on all the machines
!!    now. There are incompatibilities. nipc.library is now at
      40.68.
    - It seems that EnvoyFileSystem is now ok. I took out the
      kprintf calls and bumped the version. EnvoyFileSystem is now
      at 40.59.
    - If you had a broken volume with an empty name on the server,
      this name was propagated through to the client for RMS
      imports. As it is not that easy to access a *specific* volume
      with a name of ":", volumes without a name string will now be
      called "Unnamed". filesystem.service is now at 40.55.

    - Ouch. I had messed up ResolveName() in nipc for named local
      queries. nipc crashed really bad if you specified the local
      host name. nipc.library is now at 40.69.
    - Blush. My smart grep for active kprintfs failed. I overlooked one
      in EnvoyFileSystem. It is removed (hopefully :^) now.
      EnvoyFileSystem is now at 40.60.
    - As you all know, envoyprint.device basically sucked. I
      thought that I could fix it, but I was wrong. I redid it in C
      now. It is not compatible to the original 2.0
      envoyprint.device, it should be compatible to the
      intermediate beta assembler envoyprint.device, and it should
      be good enough for the new printing system (if it ever sees
      the light of day). With a little bit of luck, I won't ever
      have to touch it again except for bug fixes.
      envoyprint.device is now at 40.8.
    - The print spooler was also pretty messed up. I
      repaired the remaining problems like left over spool files on
      timeouts. If the printer won't accept any data, the spooler
      is capable of aborting a job by asking the user. Currently,
      this message is still in english only as this code will
      disappear anyway, once the new spooler is done. So except for
      a few bug fixes, this spooler is not that different from
      V40.8. I intend to release this patched up printing system as
      a free patch on Aminet as the 2.0 printing system is very
!!    broken. Please test the current envoyprint.device and the
!!    printspool.service in a bare 2.0 setup. Tell me about
!!    conflicts with the old config tools and/or other parts
!!    of Envoy 2.0. PLEASE, PLEASE, PLEASE! printspool.service is
      now at 40.9.
    - The memory pool handling in nipc no longer depends on
      nipcbase contents. This simplifies maintenance a little bit.
      I reworked the library startup. Now there is no need any
      longer to maintain both an internal asm and C include file
      for the nipc base. Finally, the asm include could be retired.
      This solves one big maintenance headache for good. The
      remaining kprintf got commented out, too. On 32 bit machines
      nipc could be marginally faster with entity handling now.
      I fixed 32 bit structure alignment in one place internally
      that I overlooked earlier. nipc.library is now at 40.70.

    - A fix to both the EFS client and server. ACTION_CHANGE_MODE
      handling was really, really very broken.
      The EFS server connected comment and file name on doing ExAll
      emulation. It would create locks and file handles even if it
      did not have enough memory to remember them. There wasn't
      even a basic consistency check on passed in lock or
      filehandle values. For now I added major checking code that
      can be disabled once we are sure again that nipc or
      the client don't mess up the data passed to the server. Also
      there is new debugging timeout magic added to the server. If
      you break it with CTRL-D or if you change the configuration,
      it will contact all clients on the next heartbeat and
      disconnect those that don't answer. Together with the private
      magic CTRL-F to shut down the server, this should make
      hunting for leftover locks and filehandles a lot easier!
      filesystem.service is now at 40.57.
    - The client should name the error number now if it encounters
      an unknown nipc error on a connection failure.
      EnvoyFileSystem is now at 40.61.
    - GetHostName() will fail now if the name doesn't fit into the
      passed buffer. The resolver miscalculated a buffer length
      by one when querying the host name. Actually, the resolver
      did a few messy things and used internal data without
      semaphore protection. It should do the right thing now. And
      it shouldn't crash on 68K machines any longer with misaligned
      query data. As the resolver is used on reconnects, this might
      explain some of the spurious problems we had. Some work spent
      on the S2R2 low level code. It used different types of
      IORequests for a single device. The code should behave much
      more straightforward now which should help debugging future
      problems. Ralph might like this one again. His observation
      that something very bad must have happened during the change
      40.67->40.68 was right. I never doubted it. It took me quite
      a while to figure out the problem though. It was an obvious
      bug that should have jumped in my face the minute I looked at
      the code. Under certain circumstances the packet filtering
      code caused a semaphore to be used. It is obviously not wise
      to use semaphores in interrupts. I did not realize it because
      there is LOTS of valid code using semaphores and I didn't
      notice the interrupt dependency. Ouch. The workaround means
      that the packet filtering code will no longer filter unneeded
      packets all the time. Sometimes it will let unknown packets
      through. Actually, I am not too fond of the packet filtering
      idea in S2R2 anyway. A complex protocol stack like nipc will
      be able to support arbitrary protocols, which means that
      usually some protocol list must be scanned to find out which
      packets to filter. Obviously some kind of arbitration is
      necessary here in the filtering code and most certainly I
      don't think that Disable() is appropriate on the protocol
      stack level to scan a list. This means that the whole packet
      filtering idea is flawed in terms of design IMHO as it can be
      used only for dumb stacks handling a known simple set of
      protocols. Obviously I could rewrite the code to keep a
      somewhat simple static array of packet types to be scanned
      (in addition to the list) that is replaced only during a
      Disable() when a protocol is registered or freed, but I
      really feel bad about that. I don't like Disable() even for a
      simple memory update. If you want to convince me of doing
      this because you think the filtering benefit is worth it,
      talk to me. nipc.library is now at 40.73.
    - The UDP checksum algorithm could produce a "no checksum"
      result for certain packet types. UDP also wouldn't close
      all open connections on shutdown which was not very black box
      at all. nipc.library will start throwing ICMP messages around
      now. I also added basic general IP based protocol support.
      This means that anyone can set up and register any IP
      based protocol with nipc now and take advantage of the
      complete IP layer. I can almost completely black box the
      internal protocols now and kill global interactions. Great!
      The "only" thing I still have to do now to do debugging on
      the packet level is to write a monitor protocol, simply
      displaying all the IP packets that are coming in. I still
      haven't decided on a SNMP interface though. This is very
      tricky stuff. It would sure help to have this though. At this
      time, nipc will do a kprintf for every ICMP message
      requested. Actually ICMP messages shouldn't be sent that
      often and right now it may be a good indication if we have
      any problems. One ICMP test I did was to deactivate a device
      packets were routed over with Network Configuration while a
      transfer was active. nipc took it well and started to use
      ICMP. I love dynamic configuration. It is interesting to
      observe how nipc gets more and more complex while getting
      less and less complicated at the same time. Well, it is
      getting bigger. nipc.library is now at 40.75.

    - ICMP had a wrong protocol number as I mistyped an identifier.
      So nipc wouldn't recognize any ICMP messages. IP fragments
      are no longer handled via the S2R2 device structures. They
      are now an integral part of the IP layer. Even if a packet
      definitely could not be reassembled, the reassembly code
      would loop through all the fragments. Raised the fragment
      timeout to 15 seconds. Comer uses 60 in his simple example
      code, but he also uses limited buffering. I don't want to
      flood nipc. The RDP code now doubles the timeout on packet
      retries with an upper limit of currently 20 seconds. There
      was a tiny hole in FindEntity(). With just the right timing,
      it wouldn't find an entity that was perfectly well and alive.
      RDP will no longer kill a connection if it was unable to send
      data due to lack of memory. It is much less expensive to get
      more resources again than to reestablish a connection. And
      memory is needed to do the latter anyway. RDP used to rely on
      IP fragmentation for fast networking HW by sending packets of
      about 3*MTU. As loss of a single IP packet means
      retransmission of 3 IP packets then due to the loss of the
      respective RDP datagram, I took this "feature" out.
      Fragmentation is expensive in terms of memory usage and CPU
      load anyway as buffers need to be copied. RDP will no longer
      use fragmentation! The RDP round trip time and connection
      speed estimation was garbage. This may be part of the cause
      why sometimes connections got lost. The S2R2 code will no
      longer accept devices with a MTU value less than 100 or a BPS
      value less than 1000. These are silly devices where quite a
      few things wouldn't work anyway. The transaction and RDP
      timeout setup was garbage, too. It now uses some correctly
      calculated values that actually have some meaning in real
      life. The old code screwed up timeout handling to no end,
      It even generated negative timeouts. The new code is
      basically what TCP does. It is modified for differences of
      the RDP implementation, though. We use Karn's algorithm when
      the connection is active. For establishing a connection,
      there is a fixed timeout and a few retries. The new thing is
      that RDP tries to always do a correct roundtrip time
      estimate. The result is that the transaction timeouts (which
      have always been adjusted to compensate for the transmission
      delays) should now finally be accurate. If the load on the
      net increases, nipc should no longer fiddle around with
      roundtrip times that were calculated on connection startup
      only. We have an adaptive timeout in RDP now that should make
      reconnects a lot less common. This is very hard to test for
      me though. I'd need a setup that would emulate a long delay
      on the cable. Tricky to do in SW. Maybe someone using Envoy
      with a dial up connection can shed some light on the results?
      These extra computations may slow down Envoy on slow
      machines. On an A3k/25-A4k/WE040/40 Ethernet setup, I can't
      see any noticable diskspeed difference. On packet
      loss you should still see a few kprintf's. nipc.library is
      now at 40.76.
    - If you passed an ACTION_CREATE_DIR with a ZERO baselock, an
      empty name, and just the right type of garbage in dp_Arg3 to
      the EFS client, it would do a certain amount of
      ACTION_LOCATE_OBJECT specific processing. This in result
      could produce an internal lock that would not make any sense.
      EnvoyFileSystem is now at 40.62.
    - I increased the lock and filehandle check level in the
      filesystem server again. It will try to post recoverable
      alerts now, if it encounters bad values. Maybe this helps
      locating these spurious server crashes. filesystem.service is
      now at 40.58.
    - Owner and Group will no longer print an error message twice
      or return ok for errors. Owner and Group are now at 40.3.
    - When reworking the user/group packets in the EFS server, I
      messed up some IoErr() values. Things should be back to
      normal now. filesystem.service is now at 40.59.

    - Fixed up the Service docs and added a new Tag
      SVCAttrs_FullService to be able to tell if a service supports
      SetServiceAttrsA() and AttemptShutdown(). The recompiled
      services.library is now at 40.8.
    - As of this moment I will no longer support assembly includes
      for Envoy. In the quest for portability, assembly includes
      simply will get in the way. They are also a dangerous
      maintenance hassle that already got in the way a few times.
    - After a lot of thinking I found out that the internal buffer
      management in nipc had a few holes that required a major
      check of all the involved code. There were some strange
      things to fix and it caused me some grief to rework this, but
      it should be stable again now. I am not sure if it is the
      a2065.device yet, but I had the effect that the very first
      packet written out to the device after a reload of
      nipc.library was lost. This caused a slow RDP startup. I
      worked around this for now by simply sending the RDP startup
      packet for a connection twice. This doesn't hurt RDP and
      helps startup performance by a few seconds even if a driver
      has a problem. Obviously the driver causing this should be
      fixed though. ICMP should process redirect messages now.
      Tricky to test. The UDP interface has been reworked and is
      going public about now. All of the buffer stuff has caused a
      major source change. Please test for memory leaks and
      mungwall problems! nipc.library is now at 40.77.
    - Major 2065.device rework. It did some very very nasty things.
      I hope I got them fixed now. As a side effect, interrupt load
      may have decreased. PLEASE TEST THIS WITH MULTIPLE PROTOCOL
      STACKS! This internal version is now called 3.5 to avoid
      version problems with the Interworks version 3.2.
      It supports the New Style Device standard now.

    - nipc should no longer rely on initial notification for its
      prefs file. Tss. Is there is still a fs around not supporting
      notification? :^) The sfd file for nipc is fairly complex by
      now due to the enw and still private function calls. It
      turned out that the SAS/C SLINK can only handle simple FD
      files, so nipc will no longer use SLINK, but generate a
      vector table via a simple ANSI C tool "makevectors" now. This
      is much more portable anyway. nipc.library is now at 40.78.
    - The EFS server did not set the return codes for packets
      correctly for ACTION_END and ACTION_FREE_LOCK. Actually it
      did not set quite a few return codes correctly, related to
      lock and file handle checking. I must have been drunk while
      writing that code. This should have fixed the WB copy
      "Required arg missing" problem for good. It is also a major
      rework that needs lots of testing. I also fixed a few bugs
      with packet arguments that I introduced for a future V43 OS
      (which may never come). The server will also make a lot less
!!    assumptions about FileHandle internals now. The User/Group ID
!!    conversion packets have consistent return values now, even
!!    though they are a little strange for a conversion to an id. I
      decided that probably nothing uses these packets except Envoy
      itself, so I could safely fix them.

        #define ACTION_Dummy                20000

        // res1: ID if res2 == 0; res1: invalid if res2 != 0 (res2 == error indicator)
        #define ACTION_USERNAME_TO_UID      (ACTION_Dummy+0)
        #define ACTION_GROUPNAME_TO_GID     (ACTION_Dummy+1)

        // res1: DOS bool, res2: error if res1 == DOSFALSE
        #define ACTION_UID_TO_USERINFO      (ACTION_Dummy+2)
        #define ACTION_GID_TO_GROUPINFO     (ACTION_Dummy+3)

      Don't try to define new packets around these values or any
      other values. These packet numbers are "old" C= numbers that
      finally have a usable definition. They are not an invention
      by IAM. There also was a subtle bug in ACTION_RENAME
      handling. If dp_Arg3 was ZERO, a wrong volume descriptor
      might have been used to find the correct base lock. As the
      whole return value system has been reworked, it may be
      extremely wise to do some decent testing! Notification for
      file creation did only work for secure mounts well. The
      securoity checks for file creation/open had holes. You could
      access a file even if you did not have access permission for
      its immediate parent directory. Security for ACTION_PARENT
      didn't really work at all. It was possible to lock
      directories without E permission. It checked the source
      lock instead of the result. ACTION_SET_COMMENT/DATE checked
      the directory lock, not the object they were accessing.
      ACTION_FH_FROM_LOCK accessed the lock after creating the
      filehandle. For this packet I am not completely sure how to
      handle security. In fact the whole security handling of
      many packets is debatable. What should be checked and why
      in each case? There are grey areas IMHO or I am confused.
      The big problem is directory permissions. How should they
      be treated. What e.g. about parent permissions? Afterall,
      AmigaOS is not Unix. What do you think? This is the time to
      voice your opinions and to look hard at security.
      filesystem.service is now at 40.61.
    - Finally, the EFS server should shut down pending mounts
      correctly for clients that have been turned off correctly.
      During the check, the server may pause for a few seconds.
      This is unlikely to change, but persistent probing of dead
      clients which bogged down the server should no longer occur.
      filesystem.service is now at 40.62.
    - Owner and Group support the consistent UID/GID conversion
      now. Previously they wouldn't have handled a zero Id. Owner
      and Group are now at 40.4.
!!  - A general note: Now that nipc generates ICMP messages, it is
!!    very unwise to use it along any TCP/IP stack with the same
!!    IP/ARP packet types. The stacks may confuse each other. Just
!!    bump the Envoy types by one if you are using TCP/IP on the
!!    same line.

    - There was a failure path in the EFS server where the
      ACTION_SEEK primary error result would not have been set to
      -1. filesystem.service is now at 40.63.
    - The EFS client returned wrong error codes for C:Lock'ed
      mounts for certain packets. Error handling should be safer
      here now as it is unified in the client. ACTION_DISK_INFO
      will no longer fail, even if the network is down or goes down
      during the request. If you find a failing ACTION_DISK_INFO,
      scream at me with a bug report. In case the network is down,
      a fake InfoData structure will be filled with ID_VALIDATING,
      ID_NO_DISK_IN_DRIVE. id_NumSoftErrors will contain the number
!!    of reconnects for this mount. This should fix the temporary
!!    WB lockups caused by lost server connects. Note that an
!!    ACTION_DISK_INFO will no longer trigger a reconnect! This is
      intentional. The client used to complain on unconnected locks
      and file handles left over from a previous connection.
      Typically, this didn't occur as all of them were reconnected
      right after the connection was reestablished. It could happen
      though if some part of the reconnect actions failed for
      whatever reason. The client will now try to reconnect these
      handles once again before complaining on them. Cleaned up and
      unified some packet handling. EnvoyFileSystem is now at 40.63.
    - nipc had a hole in its shutdown code that could lead to
      unexpected crashes. In entity handling, there was a semaphore
      lock messup which could have caused a deadlock for unreliable
      connections. The RDP timeout values and handling were not
      exactly great. UDP had a deadly problem with any ICMP packets
      due to two missing lines of code. In ICMP handling, a break
      statement was missing, even though that bug didn't have any
      adverse consequences at all. ICMP echo didn't. If someone
      called DeleteEntity() for an Entity that had been found by
      some remote site, the remote site was never notified that the
      Entity got shut down. Actually, to be correct, the problem
      was that the Entity was always marked for a delayed delete
      without even trying a shut down. This means that clients
      could "hang" on long dead entities for a while even
!!    though the HW was ok. MAJOR RDP REWORK. As it turned out RDP
!!    still wasn't RFC conforming at all. This release of nipc is
!!    most likely completely incompatible to previous versions.
      Especially the connection startup was messy. When shutting
      down, nipc will complain with a recoverable alert now if
      someone forgot to LoseEntity() his local stuff. On the way I
      produced and fixed a few deadlock bugs. It would be great if
      I could do RDP on a different context and have transaction
      handling run on its own context. I would only pass messages
      with data then and I wouldn't have those semaphore
      interactions. Unfortunately, doing it like this is expensive
      due to context switching. It seems that nipc and RDP are
      reliable again. I have to write this at this very moment
      while I copy quite some amount of data from the A4kT to the
      A3k to trigger any bug again. If nothing shows up, this may
      be a candidate for beta testing again. Entity shutdown via
      either DeleteEntity() or LoseEntity() had a few holes. It
      should be safe now. nipc.library is now at 40.80.
    - If you find any typos in the notes above, it is most likely
      the fault of the female german person tickling me here in
      front of my machines.

    - With the major EFS server changes, I broke
      ACTION_FH_FROM_LOCK. A line of code was missing. The
      filesystem.service is now at 40.64.
    - The client had a problem with delayed root locks. On
      resolving them, it could attribute them to the wrong volume
      if a reconnect occurred in the meantime. In low memory
      situations, the client could have returned very strange
      results on ExAll()'s. A general problem will remain for
      people exporting RAM:. If the server reboots, it will create
      a new RAM: with a new volume date. This looks like a
      different volume to the client, so the client will never be
      able to reestablish that mount correctly as expected when
      you have pending delayed root locks or obtain a delayed root
      lock after the reboot before the client noticed it. Nothing I
      can do about this. The simple fix is not to export RAM: or
      any other "volatile" volume for anything of importance if
      server reboots are likely. EnvoyFileSystem is now at 40.64.

    - nipc.library supports S2R3 now for incoming data. At this
      time I decided not to put in code for outgoing data, as the
      outgoing data buffers can have a format that may be quite
      warped. The overhead to decide on the buffer format would
      currently be excessive IMHO. I may add a simple check later
      when it turns out that the current stuff works well. The new
      event system didn't work at all. I was too hasty in a few
      places when writing the code. It should be ok now.
      Woah! While doing the changes for the new internal RDP
      interface in transaction handling, a line of code got lost.
      The trans_Error field was never set up for returning
      transactions anymore. Which means that _everything_ was
      returned as successful that didn't fail locally. This
      shoudl also fix the users/groups editors "waiting" forever
      when used with an AccountsServer. They simply collected
      one user over and over and ate up memory and CPU time. You
      are asking why the rest of the system worked fairly well
      anyway? It seems that networks and the EFS server are more
      stable than we think they are. There was also a problem in
      setting up incoming transactions. trans_RespDataActual wasn't
      set to 0 (which caused extra return traffic on the reply) and
      the trans_RespDataLength wasn't correct for magic "in place"
      transactions where request and response share the same
      buffer. I am using this beta now to test the upcoming SAS/C
      6.57 patch, too. A few warnings 317 hit me which was a good
      thing. A line of code was missing that messed up correct
      subnet matching. nipc.library is now at 40.82.

    - Cough, cough. trans_RespDataActual may not be set to 0. There
      is the silent assumption inside nipc and user code that the
      buffers will be transmitted completely if the Actual values
      are not touched by the user. In effect, you are reducing the
      amount of transmitted data if you set the Actual values to
      less than the respective buffer size. Default has and will
      now always be full buffer size. This is also documented in
      the autodocs now. Another lesson learned the hard way.
      nipc.library is now at 40.83.
    - EnvoyFileSystem had a small hole. If a reconnect happened
      while an ExAll()/ExNext() was in progress, the server would
      get an invalid lock identifier which could have really
      confused it and the client would abort early. EnvoyFileSystem
      is now at 40.65.
    - EnvoyFileSystem had a bigger hole, too. If an internal
      ExAll()/ExNext() was in progress and some error happened,
      the original packet would never get replied to. This, and a
      stupid variable usage bug that turned up due to the fix in
      40.65 made examine stuff really unsafe. EnvoyFileSystem is
      now at 40.66.

    - Recent work on nipc.library made it crash on plain 68000
      machines due to a violation of data alignment restrictions.
      I also added some minor caching for IORequests which should
      help performance. I also added a kprintf for any SANA I/O
      error that I get for now. This should help debug the backup
      freeze problem. nipc.library is now at 40.85.

    - Major overhaul of envoy.library in preparation for quite a
      few necessary tool changes. Stack usage and GUI compatibility
      need to be checked! envoy.library is now at 43.2.
    - Again RDP problems. Not with data management, but with
      semaphore locking issues. We had several unprotected areas.
      This in turn could have affected transferred data. Also RDP
      should no longer try to work with closed connections that
      much. A major RDP interface rework has been done to fix these
      problems. Quite a few LOC have been shuffled around
      without really affecting the protocol implementation
      itself. MAJOR MAGIC INSIDE. Please let me know about
      deadlocks and efficiency changes. The icmp and S2 debugging
      kprintf's are still in there. nipc.library is now at 40.86.

    - Found some problems in the requester layout code and added
      some gadtools handling functionality that I need for easier
      GUI creation. Now this stuff doesn't have to be duplicated
      all over the place. envoy.library is now at 43.3.
    - The Accounts Server had some problems. Group management could
      mess up the user id of the admin user. Finally it shouldn't
      be possible any longer to kill the last admin. It shouldn't
      be possible any longer to have duplicate group or user names.
      Accounts Manager is now at 37.19.

    - The major changes in envoy.library caused two things to be
      overlooked. The requesters didn't open active anymore and had
      no close gadget. The GUI tries to be smarter than Intuition
      now about window borders to be compatible to Intuition hacks.
      envoy.library is now at 43.4.

    - More changes to the GUI code. There were bugs in unused code
      parts for calculating sizes. It didn't get along well with
      font setups that gave reasonable results but were smaller
      than topaz 8 in either direction. I also unified lots of code
      in the requesters which did basically the same thing. This
      code should be darn smart about the layout now. Hopefully.
      UGREQ_OptimWindow was not handled. Major rework inside to
      make the GUI code more accessible to the other Envoy
      tools. The envoy.library is now at 43.6.

    - There was a deadlock in the RDP locking code in nipc.library.
      I revisited the whole locking scheme. I should be on the
      right track now. nipc.library is now at 40.87.
    - Found some more problems in a2065.device. a2065.device is now
      at 3.7.
    - Found some more problems in a2060.device. These were stupid
      to the point of embarrassment, though they didn't affect SANA2
      use of the device. a2060.device is now at 40.9.
    - The Users preferences use the new GUI engine now. Users is
      now at 37.20.
    - The Group preferences use the new GUI engine now. They
      should also handle the group list correctly now for a late
      login. Groups is now at 37.16.
    - envoy.library needed a further enhancement to support the
      new Services Configuration. The default pubscreen is now
      inherited from a specified optim window if no other screen is
      specified. This should fix general pub screen behaviour for
      most cases. A ScreenToFront() and WindowToFront() is done if
      appropriate, too. envoy.library is now at 43.8.
    - Reworked Services Configuration to use the new GUI layout
      code. Services Configuration is now at 37.16.
    - All new Filesystem Imports. Same functionality, better looks.
      Exports is a little more tricky to do. Filesystem Imports is
      now at 40.18.

    - Due to lousy autodocs and my acceptance of the word as is,
      some code in envoy.library used a V39 only graphics.library
      function. This and a couple of gadget size calculations are
      fixed now. envoy.library is now at 43.10.
    - nipc.library had a ReleaseSemaphore call that shouldn't have
      been there. nipc.library is now at 40.88.

    - Filesystem Imports no longer tells us about successful
      connections. We can see that anyway and are told about
      errors. Filesystem Imports is now at 40.19.

    - Filesystem Imports now has a NOSECURITY tooltype and command
      line option. This will suppress the login requester and makes
      maintenance of networks without security easier. Currently,
      for mounts that you want to do once in a while that should
      not be automounted, create a permanent mount and drag the
      created mount icon from DOSDrivers or (WBStartup for 2.0
      systems) to your favourite storage place. A single click will
      give you the needed mount then. FSI is at 40.20.
    - A long overdue change to nipc.library was needed to support
      envoy.library better. Frankly, this got on my nerves for a
      long, long time. Now I fixed it. NIPCInquiryA() can now be
      aborted early in a fairly decent way. In anticipation of
      a general feature freeze, the version has been bumped.
      nipc.library is now at 43.1.
    - The envoy.library host requester no longer waits. Yeah!
      Well, actually it waits 5 instead of 2 seconds now for a
      response, but you don't have to wait. Some enhancements to
      the GUI code in anticipation of the needs for reworking NIPC
      Configuration. The login request will fetch ENV:USERNAME if
      available and no user name has been given. If a user name is
      there but no password, the pw will be activated for entry.
      envoy.library is now at 43.12 and requires nipc.library V43.
    - Filesystem Imports is done. This was a tricky one, though
      NIPC Configuration will be very tricky compared to this one.
!!    The prefs format and the default file name have changed. Do a
!!      "Filesystem Exports FROM ENV:Envoy/efs.config SAVE"
!!    This should convert the data to the new format. Note that you
!!    also need an updated filesystem.service to use this!
      Filesystem Exports is now at 40.21.
    - The new prefs code fell victim to a intuition/gadtools refresh
      bug. It is unwise to fiddle around with gadtools gadgets
      _during_ a refresh as it turns out. The code did pretty
      much exactly that in a nonobvious way. Somewhere, there is a
      deadlock possibility. I took this opportunity to bump the
      versions. Filesystem Imports, Filesystem Exports, and
      Services Configuration are now at 43.1.
!!  - filesystem.service now supports the new prefs file. To avoid
!!    support problems, the old file is no longer read.
!!    filesystem.service is now at 43.1.

    - Major nipc.library rework. There were still serious problems
      in the locking scheme. I really hate this. ~120KB of sources
      are affected and have to be handled each time I touch any of
      that code. I redesigned the entity shutdown code to be a lot
      less warped. Previously, there were _tons_ of nested
      semaphore calls on multiple contexts for all the entity
      handling. Now we can count them in kilograms and I defused
      even more explosive code. Incidentally, this rework seems to
      have made nipc noticably faster. Ha, as if this would make
      it more stable :-/. I put in more paranoia alerts. Let me
      know if you encounter any of them! ALL THIS NEEDS ***HEAVY***
      TESTING! I also spent about two days tracing and debugging
      RDP packets to be sure that it works as expected. I put in
      detection code to find and kill dead passive ends of a
      connection and killed a paranoid call that resetted a
      conenction twice for no reason. There is no active probe by
      nipc to test potentially dead active ends because this would
      really mess up dial up on demand. I heard that at least one
      person is trying to do that. Oh well, I originally planned to
      get Network Configuration in shape this weekend.
      BTW, this entry crosses the 2k line in my history file!
      nipc.library is now at 43.3.

    - I broke GetHostName() for 43.3. Locking was in the wrong
      place. Well, actually, GetHostName() had another flaw that
      I didn't cause, too. I won't tell.
      nipc.library is now at 43.4.

    - I broke even more. Rework of FindEntity(). Fix of the
      dead connection detection. Clarification to the
      WaitTransaction() autodoc. Useless paranoia code
      for broken BeginTransaction() calls replaced with
      dead end alert. nipc.library is now at 43.6.
    - envoy.library missed some locking calls. For refresh support
      of parent windows, I reactivated the stone age
      (incomplete and broken!) callback support in an ASL like
      manner. envoy.library is now at 43.14.
    - Services Configuration displayed trash when removing the last
      service. Services Configuration is now at 43.2.
    - Filesystem Imports now uses a mode cycle gadget. It also supports
      a new mode "Storage", which mounts the drive and puts a permanent
      icon into DEVS:Storage/DOSDrivers. Catalog update required.
      "Temporary" as default choice is intentional.
      It also refreshes its window while the envoy.library requests are
      open. Better now, Olaf? Filesystem Imports is now at 43.3.
    - I think I stumbled over the "no write after open" problem
      with the client during testing. It was not reproducible
      though. I don't know yet what it may be or if it is the
      client or some side effect, but I found very strange error
      messages in the client along the way. The client has been
      updated to put out better error messages for some connection
      problems, which may help locating problems. Previously it
      complained e.g. that the server refused data when that very
      data didn't even leave the client due to nipc connection
      problems. A catalog update is required. EnvoyFileSystem is
      now at 43.1.

    - Users was really broken. You could create users with an empty
      name, a checkbox gadget was internally used as listview due
      to a wrong define, it reconnected to the server pretty much
      all the time, and refresh was broken. Users is now at 43.1.
    - Groups pretty much had the same problems as Users. :-/
      Both Groups and Users could be really cleaned up big time
      inside, as it is still lots of old code in the new prefs
      wrapper. This does not seem to be the time to do this,
      though. Groups is now at 43.1.

    - Angela found a bug in Filesystem Imports while clicking
      around not just a little bit. For temporary mounts, a trashed
      buffer would be used to lock the volume. Filesystem Imports
      is now at 43.4.
    - Angela found a few more bugs. EnvoyFileSystem did not take
      ACTION_INHIBIT well. More precisely, it didn't handle other
      packets well while inhibited. I did not check it with the
      RCS archives, but I suspect a source line got lost during
      editing sometime ago. The EFS client also did not take
      ACTION_DIE well with ACTION_INHIBIT being active. The Info
      results if the exported _device_ is inhibited
      now make more sense. Note that ACTION_INHIBIT
      in the EFS client is for debugging, not for
      using a disk editor. EnvoyFileSystem is now at 43.3.
    - Angela found another bug. Filesystem Exports did not refresh
      gadgets correctly when restoring the last saved prefs.
    - Filesystem Exports did not refresh the main window when
      the user requester was active. Filesystem Exports is now
      at 43.3.
    - I took out the remaining kprintf in nipc.library. I also made
      two internal routing functions public due to a very reasonable
      request by one knowledgeable Envoy user. nipc.library is now
      at 43.7.
    - Another one. Users did very strange things with the gadgets
      up to the point of not doing with the user data what it
      should have. Angela pestered me about the awful password
      handling. This led to me giving in and changing both Users and
      envoy.library to support a general password change requester.
!!    If a user _needs_ a password, s/he must chose one of at least
!!    six characters now that is not equal to the previous one.
      Users relies on at least envoy.library 43.15 now. This isn't
      a problem as previous V43 versions are not publically
      released anyway. Users is now at 43.2.
    - envoy.library changed again. Quite some rework inside to
      support the new password requester. The new password
      requester also optionally checks that a password entered is
      >=6 characters long and not equal to the old password. I wish
      I would finally get around to do something about Network
      Configuration, which may require more changes to envoy.library.
      envoy.library is now at 43.15.
    - In preparation for install changes, the Accounts Manager needed
      some rework. It will always use the next free user/group id
      now when allocating a user or group. While this could
      cause "stale" id's to be used, id's won't run out. A little
      unixish behaviour here. Accounts Manager is now at 43.1.
    - Services Configuration got new "majik" options now for me to
      be able to kill the little BuildSMPrefs hack. The CFGFILE and
      CFGLINE options take similar arguments compared to
      BuildSMPrefs, but can do more. With CFGLINE, you can specify
      a single configuration line as listed below. With CFGFILE,
      you can handle a whole bunch of them, including empty lines.
      Note: To discriminate between different lines, the first
      argument of each template must not be moved from its place or
      aliased. Other than that, the templates are pretty much self
      explaining. There is hardly any error checking, as THIS STUFF
      IS NOT FOR CASUAL USE!

        "ClearPrefs/S"

        "Service/K/A,PathName,Active/S,Inactive/S,Remove/S"

      Services Configuration could have lost memory to disk objects
      previously. It also allowed duplicate entries and handled the
      entries on the services list according to the current moon
      phase. Services Configuration is now at 43.3.
    - I added the CFGFILE and CFGLINE options to Network
      Configuration, too. Now I am able to rework the installation
      a little bit. "=Dummy" as first arguments are dummies for
      template recognition. THIS STUFF IS NOT FOR CASUAL USE!

        "ClearPrefs/S"

        "HostInfo/K/A,RealmName/K,RealmIP/K,Owner/K"

        "RealmInfo=Dummy/S,RealmName/K,RealmIP/K,UseRealmServer/S,"
            "NoUseRealmServer/S,RealmServer/S,NoRealmServer/S"

        "FlagConfig=Dummy/S,Owner/K,Gateway/S,NoGateway/S"

        "DevInfo/K/A,IPAddr,IPType/N,ARPType/N,SubMask/K,"
            "Unit/K/N,Filter/S,NoFilter/S,Active/S,Inactive/S,Remove/S,"
            "CheckUnit/S,HardAddr/K,"
            "NoHardAddr/S,NoIPType/S,NoARPType/S,NoSubMask/S"

        "RouteInfo=Destination/K/A,Gateway,HopCount/N,Remove/S"

        "LocRealm/K/A,RealmAddr,Remove/S"

        "RemRealm/K/A,Server,Remove/S"

      Note that what you are getting here is an intermediate
      Network Configuration that still has the old GUI but tons and
      tons of preparations for it inside. Without it, I can't send
      out a full archive, though.
      Network Configuration is now at 43.1.
    - Woah. Services Manager fiddled directly with the Library base
      of services.library. it also had some holes allowing for
      messy fiddling with the services lst. Services Manager needs
      services.library V43 and is now at 43.1.
    - services.library had similar holes and needed some more magic
      to support the manager. I also cleaned up the includes a bit.
      services.library is now at 43.1.
    - Some basic rework for the install script. It uses some
      features of the V43 installer now, does not need the prefs
      hacks any longer, updates the EFS config file if needed and
      has some minor improvements to get started somewhere. All the
      docs are still "2.0". I probably have to kill the amoksana
      stuff if I can't get a fixed device driver. :-/
      It *should* already allow for a clean update from 2.0 or
      previous envoy versions and a new installation. Let me know
      what happens for you.
    - nipc.library uses some of the internal services.library
      magic, too. It now depends on V43 of services.library.
      nipc.library is now at 43.8.

    - More rework to the installation. Still no in depth tests or
      improvements, but the basic bugs I introduced should be
      squashed now. Sometimes I wish I had reworked Installer at
      the time to support on demand include files. If it just
      hadn't been that messy... :-/
    - The central IDCMP handling loop in envoy.library kept on
      processing the currently available messages on an end request.
      This overwrote state variables and could cause it not to
      react to, e.g., an OK click. envoy.library is now at 43.16.
    - The problem with IOUsedTwice paranoia alerts in nipc should
      now be fixed. They came up when a new transaction was replied
      to (due to a transmission error) before being sent
      completely. Now, the transaction is only added to the async
      management when the transfer has completed. This is protected
      code to make sure that an immediate reply is not lost.
      nipc.library is now at 43.9.
    - EnvoyFileSystem did not report write protection for locally
      locked volumes correctly. EnvoyFileSystem is now at 43.4.
    - I got a bug report about C:Copy reporting filenames several
      times when copying files from a remote CacheCDFS mount. I
      still think that CacheCDFS may mess up the ExNext chain here
      as I take great care to preserve the FIB well. Nevertheless,
      I investigated the ExFOO stuff in the filesystem.service and
      found less than great handling of errors and the magic
      .backdrop/Disk.info examination. I reworked this to be a lot
      better now. Also, the first ExNext after an Examine of the
      mounted "root" should now behave according to spec, even
      though it is a little bit slower than it used to be.
      filesystem.service is now at 43.2.
    - SH**, D*****! On V37 systems, ng_TextAttr must remain valid
      and constant throughout the lifetime of the gadget or you
      will get very strange rendering for some gadtools gadgets!
      Another one of those untold stories! While comparatively easy
      to work around even with font sensitivity, this affects quite
      some amount of code.
    - Filesystem Imports preserves the mono TextAttr now. It is now
      at 43.5.
    - Filesystem Exports preserves the mono TextAttr now. It is now
      at 43.4.
    - Services Configuration preserves the mono TextAttr now. It is
      now at 43.4.

    - I broke ExamineFH with the previous rework of the EFS server.
      It would also return a user reject for a non existent mount.
      Now it should tell you that there is no mount instead. I
      think I found the cause for the "stale" lock/fh paranoia
      alerts. Very complex and heavy magic. As I could never
      reproduce them myself, I added another magic check to confirm
      my idea on this before blindly adding "fixes". Let my know
      about the next batch of Alerts and sushi output that you get.
      I also found a few less than safe checks that I fixed. On the
      way I reworked the library startup code to behave better.
      I forgot to tell you that you cannot any longer export Envoy
      mounts to avoid circular FS packet handling deadlocks.
      filesystem.service is now at 43.3.

    - Only a user with Admin rights can now use Filesystem Exports.
      Filesystem Exports is now at 43.5.

    - EnvoyFileSystem messed with the connection identification on
      an ACTION_DISK_INFO while the network was down or an error
      occurred. This is not a good idea as a reconnect will be
      triggered when needed automatically. There is no need to
      arbitrarily try to force one. Also, a mount with >65535
      reconnects should behave correctly now :^). There was a
      problem with locating a correct volume node after disk
      insertion in case the volume node name had been modified to
      avoid name collisions. The client will now use the internally
      kept "true" name to identify volume names. Locks and FH's
      no longer require two memory allocations each. DupLock() of
      an internal fake lock or a 0 lock will now also try to create
      a fake lock before contacting the server. This should help
      GetDeviceProc() based applications. ExNext() related Zombie
      locks could be freed without freeing the attached reconnect
      info. EnvoyFileSystem is now at 43.7.
    - filesystem.service had a messy way of handling the baselock
      of a mount. It could do diskchange loops on local Envoy
      mounts and possibly deadlock. This should be fixed now. I
      also added quite a few DEBUGGING kprintfs whenever a volume
      is set up or changed. There are also new paranoia checks
      inside to report on memory trashing of the internal resource
      lists for locks and file handles. This should help to
      identify the cause for bad locks. This is a debugging
      release. It should also ignore old uid's/gid's now in the
      export config as they represented a mount security hole.
      There was a basic flaw in ACTION_FINDUPDATE handling. The
      meaning for non existing and existing files was reversed,
      causing the action to basically fail to do the job whenever
      you needed it. As nobody reported any problems here, I have
      to assume that it is basically an unused action in real life.
      I enabled basic read only support as most of this feature
      stuff has been in there anyway, but there is nothing yet to
      set that kind of configuration. filesystem.service is now at
      43.5.
    - On reception of a transaction response with a response buffer
      that is too small (shouldn't happen!), a buffer could have
      been left lying around. A request for allocation of zero
      length buffers for AllocTransactionA() will be ignored now.
      Transaction structures are internally cached now, rather than
      freed immediately. This should reduce overhead and
      fragmentation. Incoming requests put together their own
      transaction rather than using AllocTransactionA(). The
      reception code for transaction data (request/reply) assumes
      that transactions are sent in a strictly sequential fashion.
      Due to the locking rework, this was no longer ensured if some
      maniac used one entity on multiple contexts in a certain way.
      This should now be safe again. There was a bug that could
      break small transactions from a slow to a fast machine.
      Incoming replies are handled according to their corresponding
      transaction which is on a wait list. Consider the following
      scenario. The transaction fits into one packet. The slow
      machine sends this packet successfully. Before it is able to
      add the transaction to the wait list now, the server has
      processed it and replied. This reply is lost on the slow
      client because the transaction is not yet on the wait list.
      If the timeout isn't set too short, retransmits will kick in.
      This seems to be the whole cause of the "5 seconds until
      reply" problem. Timing the 5 seconds led me to the solution.
      Locking was incorrect here. Sending the last piece of any
      transaction and adding it to the wait list on success must be
      atomic with respect to incoming reply processing. A wrong
      semaphore was used. I coudl _at_times_ reproduce the 5
      second thing, but never the EFS Alert problem. This current
      nipc problem may actually have been the cause for the EFS
      invalid lock paranoia alerts for packet type 15. Due to the
      missed transaction, EFS retransmits may have kicked in here.
      I just hope nothing else comes up. You may ask why it is so
      hard to get this right. Here is a short overview about the
      semaphores juggled for things inside nipc:

        - Entity:           4 each
        - RDP Connection:   4 each
        - Routes:           1 each
        - Misc stuff:       22

      There is a lot of room to err, leaving timing dependent
      issues aside completely. nipc.library is now at 43.10.

    - Reestablishing a notification did not use the correct volume.
      It tried to reference the current one which could have been
      NULL. EnvoyFileSystem is now at 43.8.
    - A change for filesystem.service. On [re]connecting, it sent
      out the mount info before establishing a current volume. Then
      it sent out the diskchange info for the volume. This caused a
      timing hole on the client. It got the mount with an info of
      "no volume inserted". Under the right circumstances, this
      caused the packet to fail with a "please insert" problem due
      to quite some concurrent activity in the client. Then the
      diskchange would be processed and the problem would fix
      itself automagically after at most ~1 second. Now, the server
      sets up the volume info before returning the mount
      transaction. This means that the client will now mount "full"
      drives whenever possible, rather than "empty" ones for about
      a second. Incidentally, the solution is in some way a hack.
      The server "finds" the volume by doing disk change handling
      internally. So it sends out a diskchange and returns the info
      about the newly mounted volume afterwards. As the client
      processes mount info in sync and knows about redundant
      diskchange messages, there is no problem of transaction order
!!    here. The debugging output is still in there just in case.
      filesystem.service is now at 43.6.
    - In severe low memory conditions the packet write stuff in
      nipc could dereference NULL pointers, writing into the
      vector table. nipc.library is now at 43.11.
    - Major rework for the GUI engine in envoy.library. It now
      supports gadget "unions" and tagging/query of layout groups
      to make pages possible. Also non-pixel scaled stretching of
      gadgets with arbitrary positioning is now supported
      correctly. Another thing is constant layout tag lists with
      presets of variable values. This should help stack usage.
      Option pages via gadget unions require a full window redraw.
      This is a gadtools problem. Well, unfortunately the layout
      engine is now about ~8.5KB big. It used to be below 8KB.
      envoy.library is now at 43.17.
!!  - Some more rework for the layout engine. You never think of
!!    everything before you actually start using your work. I did
!!    not handle some V37<->V39 issues well and was not able to
!!    fill a cell with a gadget without stretching the cell.
!!    Network Configuration is tricky and told me lessons on quite
!!    some issues. You *MUST* use this envoy.library with the stuff
!!    below! envoy.library is now at 43.18.
    - Filesystem Exports now uses two option pages, one for the
      security settings, and one for mount behaviour. The new
      envoy.library >=43.17 is *required* and a new catalog is not
      a bad idea. If you want a umask for file or dir creation
      like thing, you have to come up with a way to integrate it
      into the GUI. Filesystem Exports is now at 43.7.
    - Finally, I found the problem with the cycle gadget hit in
      Filesystem Imports. The layout is again 640x200 compatible
      now and the login requester uses the presets now if nothing
      else has been specified. The listview now has a prop font
      title for GUI consistency with FS Exports. Filesystem Imports
      is now at 43.7.
    - Services Configuration started up with a warped service
      selection. It also makes use of the new GUI tags now for
      better and consistent looks of, e.g., the listviews and
      checkmarks. Services Configuration is at 43.5.
    - Users now also has a nicer GUI. Users is now at 43.3.
    - Groups now also has a nicer GUI. Groups is now at 43.2.
    - Network Configuration uses the new GUI stuff now. Not easy at
      all. It also finally recognizes changes to the realm server
      address even if you don't hit ENTER. Network Configuration is
      now at 43.2.
    - Network Configuration now won't open envoy.library when doing
      config file based prefs updates. This is needed for a fresh
      installation. It also asks for an admin user now. Network
      Configuration is now at 43.4.
    - Services Configuration now won't open envoy.library when
      doing config file based prefs updates. This is needed for a
      fresh installation. It will also no longer open services if a
      service name is given in the config file and ask for an admin
      user whith the GUI. Services Configuration is now at 43.7.
    - The user with uid 0 is now always Admin when set up and can't
      be removed. On database creation, the "Admin" password is now
      required for the new "Admin" user. The accounts manager can
      algorithmically generate non conflicting names for new users
      now if the prefs tool passes in a NUL name. Groups and users
      without name can no longer be added or modified. White magic.
      The manager now needs accounts.library for password
!!    encryption. I don't like code duplication. You *MUST* use
!!    this accounts manager now. Accounts Manager is now at 43.2.
    - accounts.library now uses the new standard library startup
      code. It is a lot easier to maintain. Fixed numerous autodoc
      problems. accounts.library is now at 43.1.
    - Some fairly major rework of the installation script to make it
      more flexible. The user has to reboot now right after a
      deinstallation. I thought about algorithmically shutting down
      Envoy but figured that I could never play it safe with all
      the installations out there. It is now possible to chose
      installation directories for devs, libs, l, c, and locale in
      expert mode. SetPatch will always be installed to SYS:C. It
      knows that ICard users, typically have unit 1 connected. The
      problems with missing nipc config files on a fresh
      installation should be history now with the adapted
      configuration tools. All drawer icons should now be created
      when needed.
    - Users knows about the algorithmic names now and has some
      magic for a better GUI with uid 0. Users is now at 43.4.
    - Groups knows about the algorithmic names now. Groups is now
      at 43.3.
!!  - Just a reminder. The initial user/pw combination is
!!    "Admin"/"Admin". The password is case sensitive.
    - ACTION_CHANGE_MODE was broken for FileHandles in the EFS
      client. EnvoyFileSystem is now at 43.9.
    - Hmm. I still have to do something about the
      printer stuff and the disk is almost full. I probably have to
      get rid of something on that disk. Hmm.
    - Network Printing is all new now. It writes a new configuration
      file which is also read by the new port-handler. Network
      Printing is now at 43.1.
    - Reworked my new port-handler for better internal device name
      management. It also reads the new prefs file now and a
      reasonably safe shutdown is possible for debugging purposes
      if you know how. port-handler is now at 43.2.
    - With a little bit of luck, envoyprint.device should now
      internally support the magic unit handling which is used to
      easily redirect PRT:, PAR:, and SER:. Note: I do not care
      much for backwards compatibility here. envoyprint.device is
      now at 43.2.
    - The magic V37 printstart kludge is now a little bit smaller
      and no longer has a data segment. Envoy V37 PrintStart is now
      at 43.1.
    - Added logging support to nipc. Currently, we have some
      Entity, Transaction, RDP, ICMP, and SANA2 logging to a
      certain extent but the system is pretty much open ended. I'll
      add other and more logging messages when needed. To display
!!    the logging messages, you must run the new magic "NIPCLog"
!!    debug tool specifying log levels for whatever you want
      logged. The tool is in the Extras directory of the install
      disk. It can be started multiple times with different and
      even overlapping options to get different logs in parallel.
      Lack of memory results in dropped log messages. Logging is
      done async and does not affect nipc except for preparing the
      log message and using PutMsg() on it in case it is needed.
      Log levels range from 0 to 255 for each subsystem. Don't try
      anything else. 0 == no logging, 1 == log important errors,
      <100 == misc stuff, <200 == most internal things logged, 255
      == pretty much everything including functions called. You may
      want to start with 255 to see what kind of stuff is logged.
      Let me know if you see performance problems even with no
      logging at all. To avoid such problems I am intentionally not
      logging individual packets anywhere. Finally, nipc.library is
      no longer fully relocatable code because it is too big now.
      Sigh. I also added a missing tagcall proto for the route
      functions. nipc.library is now at 43.12.
    - filesystem.service will now copy an internal FIB for
      Examine_Next only when really needed. This is more an
      optimization that came when looking for a problem that
      doesn't seem to be the fault of EFS after all. So it is
      not really a bug fix. filesystem.service is now at 43.7.

    - I walked through nipc code to identify and eliminate obscure
      code and other risks. A math function used in calculating
      times in PingEntity() would destroy D2. Luckily, this didn't
      break the caller. The internal checksum function should now
      be a little more robust and maybe faster for the typical
      packet. it also handles odd start offsets now on plain 68000
      machines. Internally checksumming NIPCBuffs will now take
      buffer offsets into account. RDP packets with a totally
      broken header should not be accepted for anything now. When
      sending IP options with an IP packet (which nipc doesn't!),
      option padding was broken. It destroyed up to the first three
      option bytes rather than adding padding at the end. The RDP
      code now makes a better attempt to get the packet back in
      shape on retransmits. Previously it made assumptions about
      what the IP layer did with the data buffer and how it
      prepended buffer entries for IP headers or ARP management.
      While the assumptions were correct, I anticipate some changes
      and made RDP no longer rely on those assumptions "as is". In
      case of an error on preparing an RDP packet for output, the
      RDP code will no longer have the data buffer modified. This
      didn't affect transactions at all but is much cleaner now.
      RDP retries now count as connection activity. On retries, the
      new wait is based on the current maximum roundtrip estimate
      now rather than the current estimate. Retries are started up
      faster now if needed. All this should stabilize retry
      behaviour and fix connections where transaction would have
      timed out already otherwise. RDP logging is much better now.
      IP packet sending will now try harder to preserve the data
      areas passed in until the packet is actually sent. See the
      autodocs. An internal memory management call could have freed
      a NULL pointer in a low memory situation. I improved ARP
      handling. Packet timeouts during ARP handling are now
      connected to the corresponding ARP entries as they should be.
      With a maximum resolve wait of about 30 seconds with ARP
      tries every three seconds, ARP should now handle lousy
      connections much better and should fail a lot less. ARP
      flooding per IP should no longer be possible. If an ARP
      resolve is already pending, sent out packets will simply
      "wait" with the already existing ones rather than causing a
      new resolve try. On SANA config updates, corresponding ARP
      entries will finally be killed to avoid stale references. ARP
      logging implemented and ICMP logging fixed. I added some
      additional checks for broken incoming IP packets. Thanks to
      olsen for pushing the log idea. I may well have been to lazy
      to do anything about this subject myself. It helps a lot,
      even though the log messages make nipc bigger. nipc.library
      is now at 43.13.

    - The option page gadget for Network Configuration now has a
      label. Network Configuration is now at 43.5.
    - The option page gadget for Filesystem Exports now has a
      label. Filesystem Exports is now at 43.8.
    - nipc.library still had some problems in the checksum
      function. Added more SANA2, IP, and RDP logging. I added a
      very evil and ugly hack to throttle packets on retries. A
      retried packet will cost nipc internally about 20ms time now.
      The alternative would have been one second intervalls after
      each retried packet. This 20ms delay is to avoid flooding
      destinations while still being able to handle broken
      networking HW. Those with good connections won't be affected
      at all. I don't like this hack at all, but it seems to be
      "reasonable" compared to alternatives. nipc.library is now at
      43.14.

    - As it seems, some SANA devices may return more than MTU bytes
      of data on a CMD_READ. nipc now allocates 64 extra bytes to
      cope with those broken devices. To support this and better
      buffer management size checks, I reworked the SANA code a
      bit and removed strange use of two SANA callbacks in other
      parts of nipc. For DMA capable SANA devices, nipc now
      contains an additional sanity check. nipc.library is now at
      43.15.

    - All the prefs editors had WA_AutoAdjust disabled for some
      obscure reason which kept some of them from opening on small
      screen sizes. This should no longer be a problem. Also,
      Network Configuration did not recognize intermediate changes to
      the integer unit/IP type/ARP type gadgets well. Network
      Configuration is now at 43.7. Services Configuration is now
      at 43.8. Filesystem Imports is now at 43.8. Filesystem
      Exports is now at 43.9. Users is now at 43.5. Groups is now
      at 43.4.
    - The password check on startup was incorrect. Network
      Configuration is now at 43.8. Services Configuration ist now
      at 43.9, and Filesystem Exports is now at 43.10.
    - When obtaining the size of the sizing gadgets in the layout
      code, envoy.library will no longer request a specific size.
      Now it is left up to sysiclass to find the "correct" size
      which helps hacks and is a better idea anyway. envoy.library
      is now at 43.19.
    - nipc will now truncate incoming oversized packets rather than
      trying to allocate more than MTU bytes per packet. IP number
      changes did not update the ARP cache correctly. I changed the
      prototype for SetDeviceIPAddress() significantly and made
      NIPCControlA() public. Due to internal numbering conflicts, I
      also changed the values of previously unused tags in nipc.h
      significantly. Due to a bug in the ARP code, a NULL pointer
      could have been dereferenced. A new function
      AllocNIPCBuffEntryWithMem() is now publically available for
      more efficient IP protocol support. nipc.library is now at
      43.16.

    - Due to some problems that I encountered, I reworked
      a2065.device. Error recovery for the lance chip was pretty
      much hosed. The softint could have problems
      sending the correct packet. Multicasting and online could
      have eaten up pending write request forever. If the lance
      locks up, without apparent reason, the driver will now
      silently try to restart it. Some cleanup work should result
      in less Disable() and interrupt activity. AbortIO() was IMHO
      still flaky for R/W requests. Please test this.
    - Filesystem Exports didn't fit on a 640x256 screen anymore. It
      is now at 43.11.
    - filesystem.service no longer has enabled debug statements.
      filesystem.service is now at 43.8.
    - More work on a2065.device. It did not abort a pending event
      request correctly and reset the configuration status
      incorrectly. a2065.device is now at 3.11.
    - For better debugging you can now specify IP addresses as
      host name for FindEntity() calls. This also affects the
      host requester of envoy.library which makes use of
      FindEntity(). The sana code in nipc.library now keeps track
      of pending requests and aborts them individually on
      reconfiguration as a CMD_FLUSH doesn't cover pending event
      requests. In strange situations, this could have hung
      nipc.library. nipc.library is now at 43.17.

    - Minor enhancement to envoy.library. A private IDCMP
      management function can now be called as single shot
      callback for better support of async window management.
      Also, flags have been added internally to support shared
      IDCMPs. This was needed for the printer stuff. envoy.library
      is now at 43.21.

    - My new port-handler 43.4 now supports quite some stuff:
        1. PRT:TRUERAW uses PRD_RAWWRITE instead of sending an ESC.
        2. full duplex io should be possible.
        3. Timeout handling for PAR: and SER:
        4. Special PAR:/SER: redirection capabilities for network
           printing support for dumb applications.
        5. Can display the rate with the GUI/NOGUI options
        6. SER:FAST can be specified to get RADBOOGIE
        7. TIMEOUT=<x> can be specified for selective abort
        8. Should autoabort any timeout requester if the request
           finishes afterall.
    - I updated Network Printing to support the new port-handler
      prefs as needed. Note that printing redirection with this
      tool will not work as expected until the new print server is
      in place. Timeouts should work, though. They are always
      valid, not just when something is redirected. A timeout value
      of 0 means "wait forever"! Network Printing is now at 43.2.

    - nipc.library way a little bit restrictive about subnet masks.
      I changed a single line to make it more flexible.
      nipc.library is now at 43.18.
    - Filesystem Exports did not have the OldUID/GID texts localized.
      It is now at 43.12.
    - The all new Printer Exports is finally working as it is
      supposed to be. Note the new name with an "s" at the end.
      Note that it will write a new prefs file with a new name. It
      will not pick up old prefs. Default Exports "SER", "PAR", and
      "PRT" are prepared but not activated if they are not yet set
      up. This is to support the magic standard redirection of a
!!    client's SER:/PAR:/PRT: dos devices. It will not do anything
!!    with the old  printer stuff. Printer Exports is now at 43.3.
    - envoy.library had a little quirk in the layout engine. When
      spreading out gadgets it spread out gadget sizes even when it
      shouldn't have. I need a special requester for the new
      printing system. Rather than duplicating yet another piece of
      requester code, I unified the requester code used and made it
      accessible in majik, clean, and private ways to external
      parts of Envoy. Obviously this means that all requesters
      generated by envoy.library need to be retested in detail. Let
      me know if behaviour, memory usage, stack usage, or
      keystrokes/tabbing changed in adverse ways. BTW, the password
      entry gadgets are once again restricted in cursor movements.
      Let me know if this is a problem. envoy.library is now at
      43.23.
    - Many locale changes. Obviously this is somewhat preliminary.

    - *sigh* My last "improvement" to nipc.library killed default
      settings for subnetting which in effect tends to kill any
      kind of communication. This should be fixed now while still
      keeping the net masks flexible. nipc.library is now at 43.19.
    - *sigh* All the prefs editors used an IntuiMessage after it
      had been replied to. This bug has been in there forever and
      is also affecting the AmigaOS prefs editors, even though it
      may not be generally noticable. Groups is now at 43.5. Users
      is now at 43.6. Network Printing is now at 43.3. Printer
      Exports is now at 43.4. Filesystem Imports is now at 43.9.
      Filesystem Exports is now at 43.13. Services Configuration is
      now at 43.10. Network Configuration has been reworked as
      listed below.
    - To support a few necessary features for general interfacing,
      I decided to rework the Devices panel in Network
      Configurations. Any used SANA2 device parameter set will now
      have a unique interface name that is of use to some internal
      nipc functionality that is not of concern to the casual user.
      The program takes great pains to always keep the names
      reasonable and unique. Also, automagic gadget activation
      should help entering data a bit now. Incidentally, it works
      more like all the other Envoy prefs tools now. Hmm. In
      fact, Filesystem Exports really should use the export
      names, too. Hmm. Network Configuration is now at 43.9.
    - Another revision for the envoy.library GUI engine. I added a
      new function to put an abstraction layer into GUI creation.
      I also added a magic identifier for a new selection gadget
      that doesn't look all that new to the user currently.
      This is needed (now) by the reworked Network Configuration
      and will be needed by more stuff in the future as prefs grow.
      envoy.library is now at 43.24.
    - Another locale update. Won't be the last.
    - NIPCLog didn't pass all the options on to nipc.library.
      I also changed the version to V43. NIPCLog is now at 43.1.
    - nipc.library will now add the internal routes for the sana
      devices with the correct subnet masks. ICMP redirects,
      timestamps and address mask requests should now be handled
      correctly. Especially redirect handling was pretty bogus.
      Added UDP logging. Routes for specific hosts are now handled
      correctly even with net routes being available for the same
      net. There was a bug where routes with less significant
      netmasks that were added later would obscure more significant
      routes. A simple two slot cache should make route and ARP
      lookup faster. With two 060 machines and halfway decent
      Ethernet boards, it should be possible to get DiskSpeed to
      RAM: with >700KB/s. My test setup with an 040/40 and
      060/50 maxed out at about 695000Bps. Added some Resolver
      logging. nipc.library is now at 43.23.
    - Issue: nipc.library currently has a few non localized
      requesters for SANA problems. Should these be localized,
      too?! There may be a need for more messages in the future,
      e.g., to notify about duplicate IP addresses. Let me know
      what you think.

    - Due to a very strange bug report about unreliable RDP (hah!)
      I checked the RDP code and found a potential hole, even
      though I could not reproduce the actual reported bug.
      Plugging the hole the right way raised RDP efficiency by well
      over 10%. With the setup described above, I get peak rates of
      >775kBps now. This is through the RAM handler, EFS Server,
      a2065.device, ariadne.device, EFS client, the transaction
      mechanism on both side, RDP of course, and the IP layer.
      Pretty efficient, don't you think? Well, anyway, the bug was
      an nipc Alert about a lost RDP packet that simply can't
      happen. I added a few RDP diagnostics to catch stuff like
      this. If you want to find bugs here, keep nipclog with
      LOGRDP=10 in the background nipc.library is at 43.24.

    - There was a rather serious bug in nipc.library. Whenever you
      changed the prefs, nipc reconfigured itself. Due to the
      changes with >=43.19, it did not set up the ARP entries for
      SANA2 devices correctly again in this case. Net result: All
      connections lost. nipc.library is now at 43.25.

    - Until I find the cause for the alert in nipc that tells me
      about internally broken transactions, I added some paranoia
      code so that this data can't cause any harm in upper levels.
      Basically, you won't get an Alert 07000004 anymore. You can
      still track that problem with NIPCLog, using an entity log
      level of 1 though without flooding yourself in useless
      messages. log levels of one always tell you about serious
      problems only. This should help during standard use while at
      the same time allow us to locate the source of the problem.
      nipc.library is now at 43.26.

    - Printer Exports has slightly renamed default names. It no
      longer allows a delete of the default entries but the user
      can still rename them as she wishes. I am not sure
      that I am completely happy with this, yet. Printer Export is
      now at 43.5.
    - The first cut of the new Printer Imports tool is finally
      done. It looks a lot like Filesystem Imports. You can import
      printers for Default Printer Output, PRT:, PAR: and SER:.
      It should be possible to import multiple printers from
      different machines for each mode respectively. Each new
      import for a certain mode should override any old one
      correctly. Printer Imports is now at 43.2.
    - envoyprint.device should now handle the new printer stuff,
      too. It is now at 43.3.
    - The new Envoy Print Spooler (EPS) shows first signs of life
      for the first time ever.
      It will read and evaluate the prefs and tell the
      new Printer Imports about them. It also accepts files and
      seems to print them well. Known limitations and issues at
      this point of time:
        - Doesn't pick up old spool files after a reboot yet.
        - The few diagnostic requesters don't have locale support yet.
        - No loop protection yet. The spooler will happily print
          to envoyprint.device. Hmm. Feature or bug?
        - No command(s) for status/queue management yet. Issue:
          What should be possible/visible and for whom?
        - How the heck should errors be handled once the spool file
          is ready to print? Examples: Failure to write data to
          device or lack of memory for management data.
          I can't tell the client. Hmm. Any ideas?
        - Logins for printer exports with security don't yet
          seem to work. Probably a messed up user/pw check.
      Magical debugging feature. A CTRL-F will shut down the print
      spooler task.
      printspool.service is now at 43.1.
    - NOTE: ALL THE PRINTER PREFS FORMATS AND FILE NAMES HAVE CHANGED!
    - A few notes on how to sue the printer stuff:

        1. You always have some default exports for the server's
           parallel, serial and printer device. You also have a
           default export to get the current output device for
           any printer data generated by printer.device on the
           server, whichever that may be.
        2. Default exports can be freely renamed and turned on/off,
           but they intentionally can't be deleted.
        3. EPS exports can have security, much like EFS exports.
        4. The imports tool only handles prefs. It does not activate
           or deactivate any redirection.
           That is left for "Network Printing".
        5. Printer Imports is based on four steps
            - Select the server machine
            - Select which printer to manipulate
            - Select the mode to use for this printer
            - Connect.
           There are some implications and magical things here.
           First, you have to Connect in the "No Connect" mode to
           disconnect a printer. Any printer connected with a
           certain mode will override any previous printer for that
           mode. You can only have one imported at a time for a
           single data path. If you don't have any default printer
           output set up yet, the mode will automagically suggest
           this to you. This is for poor Joe User who doesn't care
           about DOS redirects.
        6. No reboots needed for any configuration changes.

    - printspool.service will now report printers using security
      correctly. It is now at 43.2.
    - Printer Imports would create duplicate prefs entries when
      changing the mode for an import. Net result was strange
      import mapping. It is now at 43.3.
    - Open issue: How do I handle loop deadlocks? Imagine this:
      User exports printer.device/0 as "PRT:". User imports "PRT:"
      as Default printer output. User activates default printer
      redirection. User does "echo test >prt:". PRT: uses
      printer.device 0 ==> data goes to envoyprint.device ==>
      spooler ==> printer.device 0. Boing. Any ideas?

    - I think I found a reasonable solution now that still keeps
      local printing over the spooler intact. If the spooler would
      be printing to printer.device/0 using envoyprint.device, it
      refuses to accept the job. If it would print to the default
      printer.device output currently being envoyprint.device, it
      will print to parallel/serial.device appropriately instead, to
      break out of a print loop for a local spool import. No locale
      support yet and some notification for failing writes to the
      final output device is still missing. printspool.service is
      now at 43.3.
    - I forgot a little feature in the layout functions of
      envoy.library which is good both for the code using the
      layout functions, symmetry in internal functionality, and my
      health. What it was? It's indexed extra info gadget tag
      support via one new private tag. I used this in Printer
      Imports. envoy.library is now at 43.25.
    - Printer Imports uses the new tag now, so envoy.library 43.25
      is required! Printer Imports is now at 43.4.
    - filesystem.service accepted a zero lock for
      ACTION_CHANGE_MODE which really didn't make too much sense.
      Also, via magical ways it was possible to modify protected
      .backdrop or Disk.info files on the server. If Disk.info is
      protected, it will now be read only, not made invisible. This
      finally fixes the problems with the original icon of an
      import not being used. Hard links to a protected Disk.info
      will no longer be possible either. Let me know if you find
      any way to access/modify either .backdrop or Disk.info if the
      export isn't configured to allow it. Be creative :^).
      filesystem.service is now at 43.9.

    - The EFS server now supports a new internal prefs flag for
      removeable media which is basically identical to an empty
      export name. I need this to rework the Filesystem Exports
      tool. filesystem.service is now at 43.10.
    - Filesystem Exports now behaves like the new nipc prefs or the
      printer prefs. It will display the exports in the list view
      and the path in the gadget to the right. As an empty export
      name is no longer possible to signify removeable media, you
      have a checkbox for this now. Previously empty export names
      get defaults and export names are now made unique to make
      imports non ambiguous. Net result is that even RMS exports
      can always have a decent name now without revealing what
      device on the server is used. NB: If this is used with an old
      filesystem.service, RMS support is deactivated. I don't see
      this as a significant problem as mixing installations on one
      machine is not a good idea. Filesystem Exports is now at
      43.14.
!!  - So much has changed that most likely pretty much everything
!!    is incompatible to Envoy 2.0 now. Just thought I mention it.
!!    An Envoy 2 and Envoy 3 setup won't be able to communicate well
!!    if at all.
    - Implemented a missing command in envoyprint.device.
      envoyprint.device is now at 43.4.

    - ARP code could cause enforcer hits in low memory situations.
      Added some paranoia checks and log messages to catch bad ARP
      entries. ARP cache will now be flushed on any config change
      to make sure that network reconfigurations are picked up
      ASAP. Querying sana devices via the ioctl like mechanism had
      a flaw. The IP code will now (like the ARP code) report a level
      one log message if it detects duplicate IP addresses or other
      very bad things. nipc.library is now at 43.27.
    - Sigh. Took me quite a while to locate a problem in
      envoy.library. It could happen that it called
      GT_SetGadgetAttrs() on the context of input.device. This in
      effect causes intuition to misbehave in a certain way which
      causes gadtools to mess up the gadget list in the end. Net
      result is that you get single gadgets added twice to a list
      just because you tried to disable or enable them. Ouch.
      Also, cursor positioning in the magic password gadgets
      was incorrect after a resize. All this should be fixed now.
      envoy.library is now at 43.27.
    - Even as admin, you had to know the old passwords to change
      a user's password. This was stupid. An admin can now change
      any pw. Users is now at 43.7.
    - I needed a new error code. So nipc.library got rebuilt
      because errors.h is anchored there for hysterical reasons.
      nipc.library is now at 43.28.
!!  - While writing the tutorial for the Groups preference editor,
!!    it turned out that Groups was really non functional. Tracing
!!    this problem turned up *MAJOR* flaws in *ALL* the accounts
!!    management. OUCH. Major rework for about everything here!
    - Accounts Server completely reworked. It is totally
      incompatible now to the old accounts.library. This is
      intentional and does not affect the database files.
      Lots of problems fixed. Lots of them. It is now at 43.4.
    - accounts.library reworked. Lots of internal magic added to
      support prefs editors in a decent way. Prefs editors no longer
      need to make assumptions about internal workings of the server.
!!    Note that accounts.library is much more restrictive now with
!!    respect to passed in data. Check the autodocs! Incompatibilities
!!    are intentional and accepted. accounts.library is now at 43.2.
    - envoy.library reworked. A feature in the password requester
      had to be added due to the fact that passwords are no longer
      passed back from the Accounts Server! envoy.library is
      now at 43.28.
    - Users and Groups totally rewritten inside. They should
      also behave a lot more similarly now and use decent error
      requesters. Users is now at 43.9. Groups is now at 43.5.
    - locale completely updated for the new accounts stuff.
    - Accounts Manager would allow a user to be added to a group
      twice. It is now at 43.5.
    - Added basic context sensitive help support due to a very
      reasonable request. This is reasonably simple currently to
      keep the amount of work reasonable and really works only with
      >=V39. Let me know if you think this is a problem. Services
      Configuration is now at 43.11. Network Configuration is now
      at 43.10. Filesystem Imports also tries to create icons now
      for paths that it creates and is now at 43.10. Filesystem
      Exports is now at 43.15. Users is now at 43.10. Groups is now
      at 43.8. Network Printing is now at 43.5. Printer Imports is
      now at 43.5. Printer Exports is now at 43.6.
    - printer.device not only is a pain, it really sucks. As it
      turns out, it doesn't really check io_Error on writes to the
      underlying output device. The only error indication it
      understands is a device not returning a request, i.e., the
      request timing out. envoyprint.device now contains a kludge
      _not_ to return erroneous writes. The requests are kept until
      the caller aborts them. *sigh* This most likely was the #1
      cause for network printing problems. envoyprint.device is now
      at 43.5
    - Shutting down the print spooler could lose memory. I also
      finished the basic management interface. printspool.service
      is now at 43.4.
    - Added a little Shell tool SpoolMgr to handle the print queue.
      Would be nice to make a commodity, but right now I don'thave
      the time. It would only be a gimmick anyway. spoolmgr is at
      43.1.
    - Printer Exports didn't handle the magic default printers
      well. It is now at 43.7.
    - Network Configuration could deref a NULL pointer in batch
      mode. It is now at 43.11.
    - Hopefully this is a release freeze now. Bumped
      EnvoyFileSystem to 43.10. filesystem.service is now at 43.11.
      accounts.library is now at 43.3. envoy.library is now at
      43.29. services.library is now at 43.2. nipc.library is now
      at 43.29. Services Configuration is now at 43.12. Filesystem
      Exports is now at 43.16. printspool.service is now at 43.6.
      Filesystem Imports is now at 43.11. Accounts Manager is now
      at 43.6. Users is now at 43.11. Services Manager is now at
      43.2.
    - In parallel to the context help stuff, I obviously wrote
      manual text and context help text. LOTS of text. I just hope
      it makes any sense. Please send me some feedback on the text.
    - Cleaned up and checked the full build engine. Did the first
      total cleanup of the RCS tree and build from scratch in a
      while! Today is 13.sep.98.

    - The print spooler did not work well for slow output devices.
      It had a default timeout of 30s/8KB of data. I changed this
      to be configurable and changed it to 15s/1KB as default value.
      A value of 0 means that no timeout check is done, which may
!!    cause a wait that lasts forever! Please load and save your
!!    export config once to have it saved in the new format!
      Printer Exports is now at 43.8.
    - Aside from handling the new configurable timeout now, print
      error requesters will no longer block network handling of the
      spooler. If one printer fails to accept data, others
      should continue to accept data from the network. Also if jobs
      for the printer are failing to accept data, the spooler
      should still accept more jobs. The print spooler will only
      refuse to handle transactions if it can't write the job
      files. In that case the user has to fix the problem first and
      ack the EasyRequest. You can also hold and release jobs
      currently in the print queue now. Holding the currently
      printing job means stopping the queue. Releasing it means
      restarting the queue. The printspool.service is now at 43.8.
    - SpoolMgr now reports the job status, is a little easier to use,
      defaults to "LISTJOBS" unless other options are given, and
      can hold/release jobs. SpoolMgr is now at 43.4.
    - Updated the manual and the online help to reflect the new
      variable timeout option.

    - German and english docs basically done.
    - Final testing
    - Layout tag tweak to make Network Configuration fit on 640x200 V37
      screen. It is now at 43.12.
    - The install script should be a little smarter about subdirs now.
    - Envoy 3 release. Finally. *sigh*

Heinz Wrobel

/*------------------------------------------------------------------------*/